Hacking the Parallax Badge in C
iseries
Posts: 1,475
in Accessories
I while back I purchased one of those parallax hackable eBadge units. For the price it was a steal considering you get a fully running development system with display and battery operated to boot. Even comes with the battery how sweet is that!
I recently took it off the self and started to look at it. I quickly learned that everything was written in SPIN code and that the C library look like something my cat through up and was mostly converted SPIN code.
So I set out to rewrite the code in C. Anyone getting into programming a propeller chip this may be the ticket to getting started. Many different devices and interfaces to program all in one neat package.
First I found that none of the documentation for the chips used were included in the badge documentation area. This was not a show stopper but would have been nice.
One of the nice things about the Propeller chip is you can run new code on the unit without touching the code that is already burned onto the unit. This is thanks to an external EPROM which most new chips come with them self-contained in the microcontroller.
First thing I wrote was the Charlieplex driver. This was an interesting way of using the pins to turn LED’s on and off. Good brain teaser. You need to look at the schematic to see how they are wired to get it to work. Then you need to multiplex it so that more than one LED can be turned on at kind of the same time. Also the multi-color LED’s where a nice touch to the problem. Great coding fun….
Next was the touch switches. I found these to be problematic. Even the test code that was on the unit did not do well with these switches. After doing some research and trying some test code I determined that the switches tend to bounce as they reach the tripping point. So when you touch the switch you change the capacitance of the input pin which you can monitor. The problem is that in one instance it is low and the next high and so on. In one article I read they said that the electrical frequency is projected through the body causing a 60HZ signal to be passed to the switch. In any case just checking the pin state is not enough. I actually used a timer tied to the pin to count how long the pin was at a given state to determine when the button was pressed. Push buttons may have been a better option.
The display was my next challenge and it seem to be straight forward. I don’t like these devices as they are output only. You never get any feedback that they are working. You can’t ask it if it is there or what is on the screen. You would like to know sometimes if what you sent the unit actually got there.
Anyway figuring out how the font on the Propeller chip was stored was interesting. Never thought I would ever have a use for it. In any case it proved to save some memory. I also recoded the 5 by 7 font so that I could use that as well. I also learned about drawing a straight line that I think I learned a long time ago but I think I ditched those brain cells somewhere.
The accelerometer was my next device to talk too. The spec sheet for that device does actually say what the X, Y and Z values mean. I have coded other chips and some give you raw values where other give you the G force based on a scale you set. Anyway the title on the spec sheet says 1.5 g force unit. So that means that a full value is about 1.5 g’s in that direction. In this case 21 means 1 g of force. Not too many configuration points on this device so it’s pretty straight forward.
The last item was the inferred transmitter and receiver unit. This mean oscillating the LED at 36khz so that the detector can see the light and set the pin to low. I still would like to write an Inferred transmitter and receiver but that is not finished yet.
I did however include a battery function that will display the battery level of the unit. This seem to work down to 3.2 volts at which point the function becomes screwy.
Here is a link to the source code in C if anyone is interested in hacking there badge.
https://github.com/iseries1/eBadge
I recently took it off the self and started to look at it. I quickly learned that everything was written in SPIN code and that the C library look like something my cat through up and was mostly converted SPIN code.
So I set out to rewrite the code in C. Anyone getting into programming a propeller chip this may be the ticket to getting started. Many different devices and interfaces to program all in one neat package.
First I found that none of the documentation for the chips used were included in the badge documentation area. This was not a show stopper but would have been nice.
One of the nice things about the Propeller chip is you can run new code on the unit without touching the code that is already burned onto the unit. This is thanks to an external EPROM which most new chips come with them self-contained in the microcontroller.
First thing I wrote was the Charlieplex driver. This was an interesting way of using the pins to turn LED’s on and off. Good brain teaser. You need to look at the schematic to see how they are wired to get it to work. Then you need to multiplex it so that more than one LED can be turned on at kind of the same time. Also the multi-color LED’s where a nice touch to the problem. Great coding fun….
Next was the touch switches. I found these to be problematic. Even the test code that was on the unit did not do well with these switches. After doing some research and trying some test code I determined that the switches tend to bounce as they reach the tripping point. So when you touch the switch you change the capacitance of the input pin which you can monitor. The problem is that in one instance it is low and the next high and so on. In one article I read they said that the electrical frequency is projected through the body causing a 60HZ signal to be passed to the switch. In any case just checking the pin state is not enough. I actually used a timer tied to the pin to count how long the pin was at a given state to determine when the button was pressed. Push buttons may have been a better option.
The display was my next challenge and it seem to be straight forward. I don’t like these devices as they are output only. You never get any feedback that they are working. You can’t ask it if it is there or what is on the screen. You would like to know sometimes if what you sent the unit actually got there.
Anyway figuring out how the font on the Propeller chip was stored was interesting. Never thought I would ever have a use for it. In any case it proved to save some memory. I also recoded the 5 by 7 font so that I could use that as well. I also learned about drawing a straight line that I think I learned a long time ago but I think I ditched those brain cells somewhere.
The accelerometer was my next device to talk too. The spec sheet for that device does actually say what the X, Y and Z values mean. I have coded other chips and some give you raw values where other give you the G force based on a scale you set. Anyway the title on the spec sheet says 1.5 g force unit. So that means that a full value is about 1.5 g’s in that direction. In this case 21 means 1 g of force. Not too many configuration points on this device so it’s pretty straight forward.
The last item was the inferred transmitter and receiver unit. This mean oscillating the LED at 36khz so that the detector can see the light and set the pin to low. I still would like to write an Inferred transmitter and receiver but that is not finished yet.
I did however include a battery function that will display the battery level of the unit. This seem to work down to 3.2 volts at which point the function becomes screwy.
Here is a link to the source code in C if anyone is interested in hacking there badge.
https://github.com/iseries1/eBadge