Embedded Systems: 18F452 Final Project Spr. 2007

The semester has wound down and now it’s time for my lab partner, Derek, and myself to build our final project using the PIC18F452. There are no restrictions on how what programming tools to use. So, we’ve so far determined that we’ll be writing it all in C18.

Preface

Our final project will be based upon previous lab projects. However, instead of using a magnetic-stripe card-reader, Derek found a cheap RFID reader that we’ll be using instead. A magnetic-strip card-reader is the same type of device people use when swiping their debit cards at an ATM.

What is RFID?

An RFID reader is similar to the ‘pass’ card machine. They operate in a similar way that the security turn-stiles at the local Target beep at you when the cashier forgets to remove the large plastic tag from your newly purchased t-shirt and tennis shoes. If you are a resident of Chicago, IL, you’ve seen similar RFID devices for the fast-lane of the numerous toll booths in the surrounding area.

RFID stands for Radio Frequency Identification and there are two basic types: passive and active. In order to keep RFID tags small, many of them are passive; they require no internal battery or power supply. Active RFID tags are larger, since they use an internal power source (perhaps a battery), however they have a much greater range which is beneficial in areas (like electronics toll booths) where there is an increased amount of RF traffic.

A Radio in My Pocket

Every Engineering Student has a radio in their possession and that’s how RFID devices work. They contain small antenna tuned to a specific radio frequency. The RFID devices pass within inches of an associated transmitter, the RFID devices converts the received RF energy into actual voltages and current to power up its built-in microchip. The RFID’s built-in microchip then transmits a series of digital ones and zeros that form that devices identification number.

The identification number is similar to that of the average bar-code you see on the side of your box of Cheerio’s. The transmitter also has a built-in receiver, so that when it ‘hears’ the sequence of bits spat out by the RFID device, a series of actions are performed depending upon what the RFID device is used for: open a lock, log an entry into a database, return price information, charge a toll fee to a FasTrack subscriber, or set off an alarm.

Here at the University of Iowa

During the off-hours, engineering students use a passive RFID card to gain access to the Seamen’s Center / Engineering Building. This is the kind of device that we’ll be using for our final project, which we’ll be basing around the Parallax RFID Reader Module shown in the picture above. Parallax reader is a 3″ x 2.5″ blue circuit board that uses a 2400 baud TTL serial interface. It is an ‘output only’ device that only requires a single +5VDC supply and houses an LED for a visual indication of activity.

Part of the trick with our final project will be to read the serial data from the RFID reader, while being able to output text information to a computer terminal. Since our PIC18F452 development board (shown at the top) has a single serial interface, this poses a communication problem.

One Interface?

Fortunately, the RFID reader is an ‘output only’ device, while the PC terminal CAN be used as an ‘input only’ device. A typical serial (RS-232) interface has three connections (Transmit, Receive and Ground). The RFID reader will use Transmit and Ground, while the PC terminal will use Receive and Ground and they won’t be talking to each other directly. They will be talking to our PIC18F452 or listening. They won’t be doing both.

Wait. Doesn’t RS-232 use +/- 12VDC for it’s transmit and receive logic? Isn’t the RFID reader using TTL (+5V and Ground)?

Yes. But not to worry. Our PIC18F452 development board has a MAX232 chip, which will convert between TTL and typical RS-232 voltages. We’ll need to use that chip to communicate to the PC terminal, but we don’t need it to communicate with the RFID reader. Instead of routing the output of the RFID reader to the input pin to the MAX232, we’ll route it directly to the receive pin of the PIC18F452. In fact, instead of leaving the MAX232 chip plugged into our development board, we’ll remove it and mount it into a socket that is soldered into a smaller development board.

Programming?

This would all be fine and dandy, but we still need the ability to program the PIC18F452. So, since we need some ‘bi-directional’ communication between the PIC18F452 and the computer in order to upload our (soon to be developed) program, we will route the Receive line from our development board to a switch so we can ‘choose’ which input to accept (the PIC programmer or the RFID Reader).

In the photograph above, you’ll see our PIC18F452 development board with the MAX232 chip removed and re-socket-ed onto a small square pc board. Although small, we’ve mounted the small DPDT switch to the right of the chip. The RFID Reader (held in the blue desk-clamp) is connected to the brown circuit board through four wires (+5V, GND, Chip Enable, and Serial Out).

Our initial code (written in C18), simply waits for an ID card to be placed flat and several inches away from the RFID Reader. Once the ID card has powered up from the Radio frequency generated by the RFID Reader, it ‘spits out’ its digital ID # stream, which is read back by the RFID Reader and sent to the serial input (MAX232) of our PIC18F452 development board. Our code re-assembles the ID # stream into 8-bit bytes, and sends the data out to the terminal, so we can determine what ID # was received.

UPDATE (April 28, 2007)

Spent some time yesterday trying to incorporate code from our last several projects into this final project. We are currently trying to incorporate the 12-digit keypad, but appear to have found ourselves stuck. Typically, we print out the value of the key that was pressed back to the terminal, but when we tried this Friday it didn’t work. Plus, we found that our RFID Reader no longer worked. I’ve been working this issue this afternoon and have finally found the culprit. Simply put: WE GOT LAZY. When we determined that the RFID Reader was ready to send us data, we stupidly turned around and sent data back out to the terminal –> printf(“We got data “); This erased the contents of the buffer (holding our input data) with what we wrote back out. So, when we tried to read the contents of the buffer, it was empty. There was nothing to actually read. Talk about feeling stupid. 🙁

UPDATE (April 29, 2007)

After Saturday’s fiasco, we still had more work to do with RS-232 communication. The frustrating part was the issues we were running into were not fully explained in the MPLAB C18 Manuals. The problem came from attempting to repeatedly read the ID numbers off of our RFID embedded cards (they look just like an ATM card, but blank with no magnetic strip on the back). We could read the cards MAYBE twice or three times in a row, before our C18 program would quit reading the data from the RFID Reader. We didn’t have any problems in previous labs when we were communicating via RS-232 to our PC terminal. Of course, those experiments involved serial communication at 19,200 baud. To communicate to the RFID Reader, we need so slow things down to 2,400 baud. After trying every ReadUSART, getsUSART and getcUSART command (and their variations) in the C18 Manual and tweaking the OpenUSART a hundred times, we finally hit upon the real problem: Framing & Over-Run Errors.

Errors?

What are those? Well, they are the kinds of errors one encounters often when trying to dial into AOL from 30 miles outside of town. A framing error is an error in … ‘framing’. Every byte (8 or 9 bits) sent over the line has a ‘start bit’ at the beginning and one or two ‘stop bits’ at the end. A framing errors means that the receiver didn’t see the ‘stop bits’, when it expected them to appear. Conversely, an over-run error is an error that occurs when the receiver isn’t extracting the the received bytes fast enough. This means that the receiver is a little slower than the transmitter and there exists a risk that data will be lost. The RFID Reader spits out the RFID card data at 2400 baud, without regard to how fast the receiver is extracting the data. We can’t inform the RFID Reader (over RS-232) that data needs to be re-transmitted, in case the receiver suspects it has lost some information. Under NORMAL RS-232 communications, we could, but the RFID Reader is a transmit device ONLY. It won’t receive anything.

Grrrrrr 🙁

To fix this we had to dig through the MPLAB C18 Manuals to determine what the PIC18F452 does when it wants to flag a possible framing or over-run error. Unfortunately, no matter what we did, the USART_Status variable (suggested by the C18 Manuals) did absolutely NOTHING. We had to hunt down what this mysterious ‘USART_Status’ variable in the C18 source code to find the ACTUAL status bits this variable was supposed to represent. We found the right status bits in: RCSTAbits.OERR , RCSTAbits.FERR and RCSTAbits.CREN. OERR is the over-run error bit. FERR is the framing error bit. CREN is the bit to toggle (set low, then set high) when either of those errors occur.

UPDATE (April 30, 2007)

Derek and I hammered away at this project for a few more hours. With the rest of the code in-place. It looks like we have a completed final project. We wondered if we needed to change some of the LCD messages. But, we concluded it would be easier to change the intended messages in the flow-chart. We also discussed the possibility of adding the EEPROM code, so we could add the ID card numbers & PIN numbers into non-volatile memory. It would be nice, but it isn’t necessary for our “proof-of-concept”. We will offer our final presentation on Tuesday. It should go well… as long as I don’t spend too much time ‘yaking’. Derek will probably do most of the presentation, while I will field questions during the Q&A session afterwards.

UPDATE (May 2, 2007)

The final presentation went well and our T.A. was VERY impressed as i put our project through its paces. Every-other word from his mouth was, “Cooool.”

UPDATE (May 17, 2007)

The Spring Semester is over and grades are out. Our final project must have been a hit with both our instructor and the T.A. (teaching assistant). I did poorly on the first mid-term exam in Embedded Systems. Somehow, I managed to pull an ‘A’ in that class. Here’s the PowerPoint Presentation we gave for the RFID final project. It’s been transformed into an Adobe PDF file: RFID Access Control System