Posts tagged ‘led’

PIC LED blinker (busy-wait)

LED blinker #1 circuit schematic


Beyond all doubt, the #1 beginning program in microcontrollers is the LED blinker. It’s super simple, and teaches the concept of pin voltages and busy-waits. Here is a busy-wait LED blinker program, and a walkthrough building it in MPLab.

First, the delay. This is a busy-wait delay program, busy-wait means you just burn instruction cycles for the delay, keeping the MCU “busy”. There’s a tiny bit of math behind them. First, the clock speed is 20MHz, the instruction frequency is (clock/4) so our instructions are executing at 5MHz. This gives us a period of 200ns per cycle.

I created two delay functions, for versatility, and for LCD stuff which will come later but it’s handy here. One is a “DELAY_US” which will delay a specified amount of microseconds. This is done by wasting 5 cycles (5*200ns = 1us) a specified amount of times (less than or equal to 255us, since I only made an 8-bit “delay” variable). We can learn the cycle times from the data sheet, and make it work from there.

Next, I created a “DELAY_MS” which delays a specified amount of milliseconds. Same 8-bit limitation of max 255ms, but that’s enough to have fun with… It simply calls DELAY_US a few times with specified amounts of delay, adding up to 1000us (=1ms) and repeats as many times as we tell it to.

These delays are used to make the LED blinking visible, otherwise it would blink faster than we could see (if at all, it takes a cycle or two for the pin to change state so it might not even change if we just toggle it every other cycle).

Here’s a little more PIC architecture information. The PIC’s data registers are broken into “banks” (bank 0, 1, 2, 3). Meaning you cannot get at them all at the same time, although some are mapped to all banks so you CAN get at them, important ones. We usually hang out in bank 0… This usually isn’t a problem, just something you need to remember. The data sheet illustrates it pretty well. When it comes up I’ll clarify things about it.

Also, for the I/O pins. Since they’re bi-directional, you need to choose which direction to set them to. Input or output. This is done by setting the tri-state register for the given port, for example PORTA’s tris register is called TRISA (not tough!). You set the direction of a specific bit, by setting the bit of the TRIS register to either 0 or 1, 0 meaning OUTPUT and 1 meaning INPUT. Not tough to remember: 0 = Out and 1 = In.

Source Code

Ok, first you need to make sure you have MPLab from

Once you have MPLab, download the LED Blinker (busy-wait) source code.

MPLab is a nice IDE, you’ll need to create a “project” and then pick your chip, and add the asm file to it (called a “node”). All code is going to be indented 2 spaces, labels will not be indented at all, assembler directives are either 1 or 2 spaces in…

First few lines are kinda simple, the title directive just sets a title for your project…

 title  "LED Blinker Tutorial 1"

LIST R = DEC sets the default “radix” for the program, meaning the number base. So if I put 100 in a line somewhere, it means 100 DECIMAL. If I changed it to LIST R = HEX, then if I put 100 in somewhere, it means 0x100, TOTALLY different. I find DEC easier to work with, and you can still use 0x whatever and it means HEX so you get the best of both worlds.

Next we INCLUDE the “” which will give us nice little names for our registers so we don’t need to remember their addresses, how nice of Microchip.

Then the __CONFIG line, arguably the ugliest line of code while still being fairly simple. You can see the list of __CONFIG’s in the “” file, they’re simply setting the configuration of certain chip features, the ones I have listed do this: _CP_OFF copyprotect OFF, you can set the copyprotect bits to make your chip unreadable, this is only good for a production product, don’t use it. _WDT_OFF, watchdog timer off, watchdog timer is there for mission-critical applications, it’s constantly running and needs to be reset constantly, if it isn’t reset it will reset the chip (assuming your program has locked up), we don’t need it here. _HS_OSC specifies a high speed oscillator, it’s in the data sheet. _PWRTE_ON turns on the power up timer delay, it’ll make the MCU wait a bit before executing to make sure voltage is stable, oscillator is stable, etc… _LVP_OFF – low voltage programming, dun’need it… _MCLRE_ON makes us hold MCLR high, instead of letting the chip do it…

; Variable declarations
 CBLOCK 0x20
DELAY,DELAYTMP			; delay function variables...

Now to the variable declarations, the CBLOCK directive lets us just list out our variable names, and the assembler will assign addresses for us, this is handy. The 0x20 is the starting address of general-purpose registers in BANK 0. We list em out, then end it with ENDC.

; Macro declarations
BANK0 macro           		; Switch to BANK0
  bcf STATUS,RP1
  bcf STATUS,RP0
BANK1 macro           		; Switch to BANK1
  bcf STATUS,RP1
  bsf STATUS,RP0
  movlw TIME
  movwf DELAY
  call DELAY_MS
  movlw TIME
  movwf DELAY
  call DELAY_US

Next the Macro’s… Macro’s are one of the coolest features of MPLab, it’s kinda like an inline C function, and kinda like a #define. When called, the code is dumped into where it was called from, but you can use variables in it, and even arguments to customize it’s compiling, stuff I’ll show in later programs.

Anyways, you make one by saying: NAME macro in the first column, then code. End it w/a endm. The ones I have are fairly simple and re-usable. BANK0 sets the bank bits to get us into BANK 0, go figure. BANK1 sets them to get us into BANK1, crazy!

DELAY_MILLI takes the TIME argument and loads it into W, next it moves W to the register labeled DELAY. Then it calls our illustrious DELAY_MS function which will be explained in detail down below… DELAY_MICRO does the same damn thing with DELAY_US!

; Program code
 org 0
  goto MAIN
 org 4
  ; interrupt handler

PAGE is a pagebreak for printing, though it doesn’t work for me. :)

org 0 tells the assembler to start assembly at address 0, our first instruction is to jump (goto) the label MAIN.

org 4 starts us in the Interrupt address of PIC’s… This is kind of strange and will be explained later on, for now just accept it as fact…

And if you’re wondering if we lost space for 3 instructions between 0 and 4, you’re right. :)

; Subroutines
DELAY_US			; busy wait of DELAY us
				; 200ns instruction period assumed
  nop				; (1)
  nop				; (2)
  decfsz DELAY,f		; test DELAY count (3)
    goto DELAY_US		; loop if not done (4,5)
  return			; gtfo (4,5)
DELAY_MS			; busy wait of DELAY ms
				; dependant upon DELAY_US being accurate
  movf DELAY,w
  movwf DELAYTMP		; save DELAY time
DELAY_MS_LOOP			; inner loop
  movlw 245			; load 245 (1)
  movwf DELAY			; into DELAY (2)
  call DELAY_US			; wait 245us (3-249)
  movlw 245			; load 245 (250)
  movwf DELAY			; into DELAY (251)
  call DELAY_US			; wait 245us (252-498)
  movlw 245			; load 245 (499)
  movwf DELAY			; into DELAY (500)
  call DELAY_US			; wait 245us (501-747)
  movlw 246			; load 246 (748)
  movwf DELAY			; into DELAY (749)
  call DELAY_US			; wait 246us (750-997)
  decfsz DELAYTMP,f		; test DELAYTMP count (998)
    goto DELAY_MS_LOOP		; loop if not done (999,1000)
  return			; gtfo (999,1000)

Next we have our subroutines, the delays, I have these before the main lines of code just out of habit, it’s not required.

DELAY_US… Pretty simple really, we start out by burning 2 cycles, so we’ve waited 400ns so far, next we decrement our counter, and test if it’s zero, if it isn’t, we goto DELAY_US, looping again, if not, we return. The test itself takes one cycle (600ns so far) and either the goto or return take 2 cycles (1000ns = 1us) so we have our microsecond delay!

DELAY_MS works on the same principle, it’s accurate enough for this! :)

; Mainline of code
  bcf TRISA,2			; PORT A, bit 2 is our output pin.
  bsf PORTA,2  			; set her.
  DELAY_MILLI 250		; wait 1/4 sec
  bcf PORTA,2			; clear her!
  DELAY_MILLI 250		; wait 1/4 sec!!!!
  goto LOOP_BEGIN		; forever... :o

MAIN is our label for the beginning of the code, jumped to by the first line up @ org 0. BANK1 gets us into BANK 1 so we can set our bit direction, we clear bit 2 of TRISA making bit 2 of PORTA our output pin, then we hop back to BANK 0…

Then our introductory programming teachers worst nightmare, a purposely created infinite loop. We label the beginning, then set our pin high, shutting off the LED (as you’ll see in the wiring diagram). We wait 250ms via our handy delay function, then clear the bit, turning the LED on, we wait again and loop ad nauseum.

‘end’ tells the assembler to give up…


Alright, so we have our program, we run the assembler by clicking the weird funnel icon or by going to Project -> Build Node (or All). It’ll crunch and come up with no errors (of course). ¬†Then just toss it into the programmer and feed the chip your tasty code.


The assembled circuit

The assembled circuit

Wire up the circuit as in the schematic at the top of the page. Hopefully it illustrates to you why the LED is on when the bit is off, and off when the bit is on… The LED is a typical ~2V yellow LED… Wired up it should look something like the image.


Hook up +5V and Gnd, and fire it up! If everything is set up correctly you’ll get a steady blinking LED!

Something to try

Connect a momentary switch to the _MCLR line, wired to Ground on the other side. Pushing the button will reset the chip, releasing it will start it over from the beginning of the program, of course it will do the same stuff, but this demonstrates how the reset buttons work. I also highly recommend changing the code to add a more interesting blink pattern, longer/shorter delays, and other stuff to get used to modifying code…