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.
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 most people use to swipe their credit / debit cards when making ATM withdrawals or purchasing clothes at your favorite retailer. An RFID reader is similar to the ‘pass’ card machine that an elephant used to purchase cold / flu medication for his favorite zoo keeper in a recent commercial I’d seen on television. 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. Everyone has a radio in their possession and that’s how RFID devices work. They contain small antenna tuned to a specific radio frequency and when the RFID device passes within inches of its 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 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.
How do we communicate with two devices with only 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.
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.
(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. 
(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.
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.
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 and CREN is the bit to toggle (set low, then set high) when either of those errors occur.
(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’ll have to offer our final presentation on Tuesday, which 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.
(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.”
(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). Somehow, after doing poorly on the first mid-term exam in Embedded Systems, 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
On Tuesday, July 31st of 2007, one of the finest people I have met here at the University of Iowa will be boarding a plane in Cedar Rapids and flying back home to Libya. I have no idea why Tariq has decided to leave this fabulous jewel of the Midwest, but I’m sure he knows what he’s doing. I’ll have to trust his judgment. In all likelihood, I will never see him again and it is just now starting to sink in. Until last week, I had never hung-out with him outside the Engineering Building at the University of Iowa. Until our dinner with Mehmed, Ahmed, Ahmed, Mike and myself, I had never chatted with him extensively in a more social environment. Of course, he was always picking my brain on the latest audio/video editing software or clues to solving his Data Structures homework. I was always more than happy to add my two-cents worth. He has always maintained a very relaxed sense of self that was refreshing and a tad addictive. I’m sure he was just as stressed as the rest of us, but he seemed to take it all in stride. Tariq has always appeared a rather level-headed guy.
During my tenure here at the Univeristy of Iowa, I had never had a class with the guy. He was always one semester ahead. We became acquainted through mutual friends, Mehmed Diken (“Bill” for short) and Ahmed Halaweish. I had gleaned from several conversations that Ahmed was a native of Egypt, which unwittingly caused me to assume that Tariq was from Egypt as well. Oddly enough, this facade continued for an entire year and I was none the wise. It wasn’t until shortly Angie’s graduation party did I realize my unintentional assumption. I had posted a photo up on Facebook with the title, “Two Egyptians, a Turk and a Cowboy walk into Buffalo Wild Wings…” I had struggled with the title; then realizing that there is a general “rule of threes” in common joke writing (i.e. “A Lutheran, a Catholic and a Protestant walk into a bar…”) I had inadvertently tossed Tariq into the “Egyptian” category and he called me on it less than a week later. “You know I’m not from Egypt, don’t you?” I had to admit that I had failed to ask where he was from… I just assumed. Fortunately, Tariq has one of the most forgiving attitudes, so he let my “faux pa” slide.
The joke continued later that summer when Tariq, Mehmed and myself went out for lunch at The Airliner. While we were waiting for our pizza (sans pork products). We were chatting about the last semester and the many difficulties that we had to overcome when I simply looked over at Tariq and stated rather dryly, “You know, you were so much cooler when I thought you were from Egypt.”
Hopefully, Tariq will continue his Libyan Mentality TV blog while back home. He’s been working on it as “…a venue to show sides of Libya that are unprecedented, whether it is in depth interviews of common everyday characters or events that rarely take place.”
