I am new to programming and a extreme novice in electronics. I first purchased a microchip PICkit 3 debug express. I had problems with the program lessons with this kit. Others recommended the Gooligum kit. I purchased that and can go through the lessons but am baffled with what I am actually doing. I don't understand what movlw actually does. I read it move a literal to register W. but what is register W? Is there are there other regiters like A,B and C? And what is a literal?

Is there a book or website that will help a novice like myself understand what I am actually doing?

 

A literal is the same as a constant. It is a number that you want to use in a calculation. If you want to know how many weeks there are in 54 days, you would divide by the constant, 7. "movlw" is followed by the constant, so the instruction should be "movlw 7". In this case, the register W is a reference to one of the general purpose registers.

This web site might help.
This page is for the instructions of the PIC.

 

The PICkit 3 debug express is an excellent starting place: you have a known and tested development board and programmer (which also serves an a debugger). Plus a set of tutorials to get you running.

The "gotcha" is the compilers are always changing (for the better really) but some of the details in how to use them change very fast, meaning parts of the tutorials, those important step-by-step instruction how to build the code simply do not work any more.

No worry... you can ask here or the Microchip forums and everyone will be happy to help.

"W" is a special register in the PIC. Many computers have at least one register where the work is done. Most of the 32 instructions on the baseline devices deal with W in one way or another, loading it, storing it, adding, subtracting, or shifting the value stored in W.

"Literal" is a fancy word used to mean a (constant) number you know when you write the program (known as "compile time") (as opposed to "run time"). The number of days in the week doesn't change and you know it when you write the program, so using the literal 7 is a good thing.

AFAIK the PICkit II development kit has tutorials written for assembly. You may want to read some of those to acquaint yourself with .asm, otherwise use C (it's free to download) with the PICkit III tutorials.

 

get datasheet of your MCU and look at the MCU structure.
w is what they call working register (on other platforms known as Accumulator).
it is where you do all the work... (fetch something from RAM, throw it in W, perform computation, put result back in RAM, and - that's it, now keep working...)

when performing computations you can use variables or constants. variables are named (i, j, count, whatever). constants can be named too but don't have to. think of literal as hardcoded constant.

 

One approach is to start out with the most brain-dead PIC you can find. Their baseline parts have as few as just 33 instructions (there may be even something smaller) and many of these are slight variants on each other. So you really only have a couple dozen that you have to understand (and it's actually less than that because once you understand ADD, it doesn't take much time to understand SUB). If you get the datasheet for that part, it will walk you through the architecture quite thoroughly and it will very explicitly go through each instruction saying exactly what it does, including which status bits are affected and how.

With that in hand, start walking through simple code snippets -- a half dozen instructions in some cases -- and see if you can play-the-PIC, meaning you pretend you are the processor and you carry out the instructions using registers that are nothing more than index cards or columns on a sheet of paper. Then start modifying or enhancing those snippets to get your feet wet at using the instructions to perform the tasks you want it to do.

Oddly enough, in another thread I just made this exact same recommendation, though for a slightly different reason. But I think you would very greatly benefit from a project-based book called The Elements of Computing Systems. Here's what I said about it over there:

One really good book that takes this approach (though admittedly in simulation/emulation) is The Elements of Computing Systems (a.k.a., Nand2Tetris). With that you will start with NAND gates (and DFFs, too) and from there build up not only the hardware (again, in emulation) but also write an assembler, a virtual machine, a compiler, and an operating system. The compiler is for an object-oriented language comparable to a leaned down Java. The OS library you write includes math functions, graphics, console character generation, dynamic memory allocation.

When you are done you have a shockingly capable machine (given how utterly braindead the processor is) and you know how every last little bit of it works (except what happens on the other side of the memory bank that is used for memory-mapped I/O for the keyboard and monitor).

The book is about $28 and everything else you need is completely free whether you buy the book or not. In fact, the first half of the book can be read on their website and all of the projects are there. So you can get the entire hardware finished and the assembler written before you get into material that requires you to actually have the book.

 

Why don't you try a few programming exercises in C? It would be much easier to understand, and once you start thinking line a computer, you can go back to the assembly code.

 

Why don't you try a few programming exercises in C? It would be much easier to understand, and once you start thinking line a computer, you can go back to the assembly code.

IMHO, this is the wrong progression. Learning how embedded controllers work by programming in C is like travelling the world by airplane and never landing! In both cases you can say you've traveled the world, but only by huffing it on the ground can you say you've experienced the sights, languages, and cultures.

C is only easier to understand in the sense that it abstracts and obscures what is going on in the silicon. This is an advantage for a lazy application programmer on a deadline, but it is a disadvantage for someone who actually wants to learn how MCUs work, which, apparently, is the OP's intention.

 

Programing in C doens't mean one is lazy. High level programming languages makes one more productive and really unlocks the power of processors. Hell, my first language was BASIC, and I was never disadvantaged in any way when it came to learning processors. It gets easier with each language, and so going from high level to low level languages is an easier path. There is much that can be accomplishd with micro-controllers without needing detailed knowledge of the architecture.

 

There is also a course avail here.
http://www.amqrp.org/elmer160/lessons/index.html
If you program in C you don't have to worry too much about bank swapping with the 16F etc.
Having said that I prefer assembler, just because I got the experience with earlier micro's.
If you do pursue the 16f in assembler, personally I would recommend graduating to the 18f later, no bank switching and a few more powerful instructions that make it easier.
Also
http://www.winpicprog.co.uk/pic_tutorial.htm
Max.

 

...There is much that can be accomplished with micro-controllers without needing detailed knowledge of the architecture.

And much that cannot.

 

Thanks everyone for your input. I have tried to use the debug express lessons. But the lessons are for MPLAB 8 not MPLAB X which I have. And it confused me. I am now playing with the Gooligum kit and they do have lessons for MPLAB X in it. The processor I am currently on is the flasher lesson. It works fine but I wanted to tweak the flash speed and couldn't figure that out.

 

Thanks everyone for your input. I have tried to use the debug express lessons. But the lessons are for MPLAB 8 not MPLAB X which I have. And it confused me. I am now playing with the Gooligum kit and they do have lessons for MPLAB X in it. The processor I am currently on is the flasher lesson. It works fine but I wanted to tweak the flash speed and couldn't figure that out.

I am still learning how to use X in my spare time. It is a "universal" development environment, and has lots of nice features. Unfortunately there is *much* to learn to become proficient at using it. I still use MPLAB for development work.

While MPLAB support is going to be dropped (has it already?), you may find getting started with the latest (last?) version of MPLAB easier than X. X can later import your .mcp file if you need to move to that platform.

This may save you some headaches, and allow you to spend more time learning to code than learning to use a development environment.

My 2 cents.

 

Does your code look like this:

void main()
{
// Main loop 
while (TRUE)
{ 
output_b(0b000010); // turn on LED on GP1 (bit 1)
delay_ms(200); // stay on for 200ms
output_b(0); // turn off LED (clearing GPIO clears GP1)
delay_ms(800); // stay off for 800ms

} // repeat forever
}

See the "delay_ms(200) instruction? Change the number 200 to something else.

 

Here is the code I was given:

 list        p=10F200           
    #include    <p10F200.inc>   


;***** CONFIGURATION
                ; ext reset, no code protect, no watchdog 
    __CONFIG    _MCLRE_ON & _CP_OFF & _WDT_OFF


;***** VARIABLE DEFINITIONS
        UDATA
sGPIO   res 1               ; shadow copy of GPIO
dc1     res 1               ; delay loop counters
dc2     res 1


;***** RC CALIBRATION 
RCCAL   CODE    0x0FF       ; processor reset vector
        res 1               ; holds internal RC cal value, as a movlw k


;***** RESET VECTOR *****************************************************
RESET   CODE    0x000       ; effective reset vector
        movwf   OSCCAL      ; apply internal RC factory calibration 


;***** MAIN PROGRAM *****************************************************

;***** Initialisation
start    
        movlw   b'1101'         ; configure GP1 (only) as an output
        tris    GPIO

        clrf    sGPIO           ; start with shadow GPIO zeroed

;***** Main loop
main_loop
        ; toggle LED on GP1
        movf    sGPIO,w         ; get shadow copy of GPIO
        xorlw   b'0010'         ; toggle bit corresponding to GP1 (bit 1)
        movwf   sGPIO           ;   in shadow register
        movwf   GPIO            ; and write to GPIO

        ; delay 500ms
        movlw   .244            ; outer loop: 244 x (1023 + 1023 + 3) + 2
        movwf   dc2             ;   = 499,958 cycles
        clrf    dc1             ; inner loop: 256 x 4 - 1
dly1    nop                     ; inner loop 1 = 1023 cycles
        decfsz  dc1,f
        goto    dly1
dly2    nop                     ; inner loop 2 = 1023 cycles
        decfsz  dc1,f
        goto    dly2
        decfsz  dc2,f
        goto    dly1

        goto    main_loop       ; repeat forever


        END

 

Change this line:

movlw   .244            ; outer loop: 244 x (1023 + 1023 + 3) + 2

make the .244 , say .122. That should speed up the blinking. A larger number should slow it down. (if it's an 8-bit register, the largest number you can use is 256)

Seriously, you could make things easier for yourself by using the C compiler.

 

Ok, So I first entered in .500 and it did not effect it at all. Never tried a smaller number to speed it up. I will try that. So I had it correct when I tried to change that number to change the speed. When it didn't work it just confused me.

The reason why am using assembly is it is just how the lessons are going. After this chapter it moves on to C. I thought it would be best to start from the beginning since I'm a novice.

 

Ok, So I first entered in .500 and it did not effect it at all. Never tried a smaller number to speed it up. I will try that. So I had it correct when I tried to change that number to change the speed. When it didn't work it just confused me.

The reason why am using assembly is it is just how the lessons are going. After this chapter it moves on to C. I thought it would be best to start from the beginning since I'm a novice.

Make sure you save your asy file and re-assemble it! Unless you do all the steps, you won't see any change.

 

Oh...yeah, I may have just changed it in the text window and run the program from MPLAB X without building it again.

 

Ok, So I first entered in .500 and it did not effect it at all. Never tried a smaller number to speed it up. I will try that. So I had it correct when I tried to change that number to change the speed. When it didn't work it just confused me.

The reason why am using assembly is it is just how the lessons are going. After this chapter it moves on to C. I thought it would be best to start from the beginning since I'm a novice.

.500 is a 9-bit value. If you are working with an 8-bit part, the behavior when you assemble it may be undefined, but the most likely result is that you would end up with .500-.256=.244

 

IMHO, this is the wrong progression. Learning how embedded controllers work by programming in C is like travelling the world by airplane and never landing! In both cases you can say you've traveled the world, but only by huffing it on the ground can you say you've experienced the sights, languages, and cultures.

C is only easier to understand in the sense that it abstracts and obscures what is going on in the silicon. This is an advantage for a lazy application programmer on a deadline, but it is a disadvantage for someone who actually wants to learn how MCUs work, which, apparently, is the OP's intention.

It may be the way you did it. It's not the way I did it. It's not the way the majority of people do it either.

If assembly is so good, why is it used in just a slim minority of cases?

Got a recent want ad for assembly programmers?