Dec 17

PIC18F2550 Assembly Tutorial 3

In this tutorial we’ll continue with the serial communication between 2 microcontrollers. You should always configure one PIC as master while all the others are to be configured as slaves. For more information check this SPI explanation.

SPI Master-Slave Configuration

SPI Master-Slave Configuration

Check the datasheet to see which pins are SDO (output), SDI (input) and SCK (SPI Clock). Once you have connected the PICs there are a couple of registers that need to be set.

This is for the master:

MOVLW	0x00	; Datasample middle, SCK act-idle.
MOVLW	0x32	; SSP enabled, Idle at high, Fosc/64

As you can see we use the internal timing components for the SPI clock, however you can opt to use TMR2 as well. Don’t forget to enable TMR2 and set its T2CON register if you do this.

This is for the slave:

MOVLW	0x00	; Datasample middle, SCK act-idle.
MOVLW	0x35	; SSP enabled, Idle at high, SPI SLAVEMODE

Make sure you don’t make a mistake here, if you have your CLK idle at high, see to it that the transition is configured correctly else you’ll miss the first pulse. For example, when the CLK is idle at high, its first pulse will be from high to low. When you configure the slave that it should do something when the CLK goes from low to high you will have missed that first pulse resulting in missed or incorrect data.

Now you have configured both master and slave you can send any data you wish. Let’s take a look on how to transmit data from master to slave:

   goto	Main                    ; Infinite loop
   bcf		PIR1,ADIF	; Clear AD converter flag
   MOVFF	ADRESH,SSPBUF	; move ADRESH to send buffer
   bcf		PIR1,SSPIF      ; Clear the flag
   MOVFF	SSPBUF,PORTB    ; Move received data to PORTB
inter				; using single interrupt priority
   BTFSC	PIR1,SSPIF	; if set-> transmission finished
   CALL	SPIread
   BTFSC	PIR1,ADIF	; wait until AD finished -> send
   CALL	SPIsend

In this example I’m sending values sampled by the AD converter to the slave. The code is pretty self explanatory. The ADC will generate an interrupt when it’s finished with converting and the SPI will generate one when it’s done transmitting the data that was in SSPBUF, which is the send buffer.

The slave has even simpler code:

   goto main
   bcf 	  PIR1,SSPIF
   movff  SSPBUF,PORTA
   CALL   SPIread			

The slave will generate an interrupt when the data byte is received, you just have to move the data in the buffer to another register such as PORTA if you’d like to display the data with LEDs for example.

Dec 15

PIC18F2550 Assembly Tutorial 2

This time we’ll take a closer look at using the flash memory and grabbing data from the program memory. This is used for a wide variety of things such as sine lookup tables. In this example we’ll display some letters (for example your name) on a seven segment display attached to PORTB. I’ve used a Kingbright one if you’d like to do the same, check out the datasheet for the SC56-11GWA.

We start by adding a software flag variable and putting the letter data in the program memory. I’ve put in “FEZ” in the following code bit:

  intFlag equ 0x29
  org 0x820
  DATA 0x71, 0x79, 0x5B

The org directive will tell the compiler to put whatever is coming next in the program memory starting at the address given, 0x820 in this case. The DATA command says which data should be put there. Make sure your other org parameters are correct else you will overwrite other bits of data (the compiler should warn you about this). If you have no idea how 0x71 corresponds to the letter F, I suggest you check out the datasheet of the 7segment display and the following part:

  MOVLW 	0x00 		; Value used to initialize data direction
  MOVWF 	TRISB 		; Set RB as outputs for 7-segment
  ;	RB0 segment 0				0
  ;	RB1 segment 1			5		1    
  ;	...				    	6
  ;	RB6 segment 6			4		2
  ;					      	3   	  7

We configure PORTB as output (do the same for PORTA and C because you should never have floating inputs!). The numbers correspond to the pin of PORTB I connected.

We’d like to be able to see the letters on the display so we need to add some delay, unlike last time where we use software and waste cpu cycles we’re using Timer 0. Time to configure its registers!

  movlw  0x20  ; Disable peripheral - enable TRM0 interrupts
  movwf  INTCON
  MOVLW  0x87   ; 0b10000111;   Presscaler 1:256    
  MOVLW 0x80 ; 0b10000000

A prescaler of 1:256 should be enough, this will make TRM0 overflow about once a second. When it overflows an overflow flag is set and an interrupt is generated, we’ll take a look at that in a minute. The EECON1 is associated with flash & EEPROM memory, take a look at the PIC’s datasheet to see how it’s configurated.

  BTFSS INTCON,TMR0IF  ; Check if TMR0 has overflowed, if not, just return
  BCF INTCON, TMR0IF   ; Mandatory clearing of the TMR0 overflow flag
  BSF  intFlag, 0      ; Set our own software flag

Every time TMR0 overflows it’ll generate an interrupt, but other things can generate one too so we need to check if it was actually the timer who caused it. You HAVE to clear the flag yourself, it isn’t done by the hardware once it is set.

Now we have our registers set and our interrupt routine finished, let’s take a look at the main program:

  CLRF TBLPTRU       ; Set the inital Tabel Pointer values
  MOVLW  0x08
  MOVLW  0x1F

Since we put our data at 0x820 we want the table pointer to point one memory address before the one we want, it’ll become clear why that is with the following part of the code:

  BTFSS intFlag, 0        ; Check if we set the software flag in the interrupt
  GOTO	Main
  BCF  intFlag, 0         ; Here too, we need to clear it if it was set
  INCF  TBLPTRL           ; increment the pointer by one more address
  TBLRD*+                 ; Read the data which TBLPTR is pointing to & increment TBLPTR
  MOVF TABLAT, w          ; Move the readout to W
  MOVLW 0x25              
  CPFSEQ TBLPTRL          ; Have we read out the 3rd letter? Jump back to the first
  GOTO Main
  MOVLW 0x1F
  MOVWF TBLPTRL           ; Set the initial value again
  GOTO Main

So what happens here? We first check to see if we have our software flag high to know TMR0 has overflowed, next we clear it, then we increment the TBLPTR once more so it’s at 0x820. TBLRD*+ will read the data the TBLPTR is pointing at, it’ll also increment the TBLPTRL’s value by one (for some reason it incremented it by one for me, although it probably should increment by 2, not sure why that’s happening). The data is read to TABLAT (table latch), which can then be moved to the working register and moved to PORTB (you can do this in one command by using MOVFF). Once we’ve had all 3 letters, we have to put TBLPTRL back to its initial value so we can start allover.

Now connect your 7-segment display to PORTB and check if it’s working! Also a quick note, I’m using 18F2550 PICs but you can just as easily use a 2553.

If you’re satisfied with the result, continue to tutorial 3.

Apr 12

Motion Controlled Maze Puzzle

Every semester at GroupT there are “Engineering Experience” projects. Last semester I was part of the team who made the MuzaBot. But this time it was more serious. Designing our own PCB, selecting electronic components and reading lots and lots of datasheets gathering information we needed for our somewhat ambitious project.

The assignment was pretty simple: Design a competitive game with any electronics you like (but no LED matrices).

Pretty easy to come up with an idea, right? Wrong! A lot of people went with cliché stuff but, as always, we wanted something more. After some  brainstorming we got our proposal approved, we were going to build a Motion Controlled Laser Maze Puzzle. In the end it boils down to this:
You are given a Wiimote with a custom accelerometer,  and you wave around in the X-axis to spin a steppermotor which turns the angle of a mirror, likewise for the Z-axis. These mirrors deflect a laser beam, the purpose of the game is to guide the laser beam into a sensor which will defuse a bomb.
To make it somewhat more like a game, the bomb has a timer, so you have to be relatively quick or it’s game over. We’ve also added a moving wall which can obstruct a possible path of the laser beam, however, you can counter this by blowing into a mic.

There are three game difficulties:
Easy: wall doesn’t move
Normal: wall moves at certain intervals
Hard: wall moves at certain intervals and your controls get inversed at times.

That’s the idea for the game, the actual implementation was done with a PIC microprocessor (2553), software was written using C18 and the maze was milled and carved out of a wooden block.

The Wiimote controller

Wiimote disassembled
Wiimote disassembled

We opted to use a Wiimote because many people recognize it as a motion sensing controller. As we had no interest to use its bluetooth capabilities so we threw out most of the electronics and replaced the connectivity with a good old RJ-45 jack and an ethernet cable.

We ordered a Wiimote at DealExtreme which costed only $12 and started to take it apart.

The PCBs

Not much to say here, we had to use Eagle to design the  boards. Most schematics were pre-made for us (e.g. the mic pre-amp) so the most time went into making the actual pcb design. Even after countless of hours it’s probably below average quality but then again we haven’t had classes yet on how to create one.

"Main" pcb
“Main” pcb

Mic pre-amp
Mic pre-amp

These are the designs we came up with after several hours of trying different layouts. Both PCBs will be connected with a header to form one board, we had to split them up for money reasons as they’re ordered at some factory.


Using MPLab to compile our code, sure, but don’t ask me to code in their IDE. For someone who’s used to Visual Studio this is a huge leap backwards. Luckily MPLab supports external editors which I set to PSPad which at least supports tabs.

As for the programming, luckily I had a C class this semester as well that has thought me a bit about coding in a procedural language (Visual Basic 6 has been way too long ago) rather than C# or Java. We spent some time structuring the code in several header and c files. The code will be posted in the next update.


That’s what we’ve got so far, after the Easter Holidays we get our PCB and components. We then have two to three weeks to get everything working, which shouldn’t be too much of a problem.