Print PDF
Favorite
Email
Step 4Software
The software really makes this project tick!
The source code in the 12F609 is really complicated. I am using ever last memory location! All 64 bytes have been consumed by my code. I have a whopping 32 bytes of flash left over as spare. So, I'm using 100% of the RAM and 97% of the flash. However, it amazing how much functionality you get for all that complexity.
Communication to each lamp is archived by sending eight-byte data packets. Each data packet ends with a checksum - so really, there is seven bytes of data plus a final checksum. At 9600 baud, one data packet takes just over 8 milliseconds to arrive.
The trick is to multitask while the packet of bytes is arriving. If any of the LEDs are active with a PWM signal, the output PWM must be keep updated even while receiving new packet bytes. That is the trick. It took me weeks and weeks to sort this out. I spent a huge amount of time working with my Logiport LSA trying to follow each bit. This is some of the most complicated code I have ever written. It is because the micro is just so limited. On micros that are more powerful it is easy to write loose/easy code and have the speedy micro rip through it without complaining. With the 12F609, any loose code with cost you plenty. All the micro source code is written in C except for the interrupt service routine.
Why have such large data packets you may ask. Well, because we want to have the LEDs ramp up and down on their own accord. Once a ramp profile is loaded, the LED can go off and start ramping even while receiving new commands for another LED. Each lamp has to receive and decode all data packet traffic even if the packet is not meant for it.
A LED profile consists of a start level, start dwell time, ramp rate, top level, top dwell time, ramp down rate, bottom level. See diagram attached. Wow, that is a lot for one LED. Now, multiply that times the number of LEDs. It becomes too much - I could only keep track of three LEDs with full ramp profiles. The fourth (white LED on the dev board) only has ramp from/to capability. It is a compromise. Have a look at the attached pic of a ramp profile.
The PWM signal is generated off a timer that is running at 64uS per tick. The eight bit timer rolls over every 16.38mS. This means the PWM signal is running at 61.04Hz. This is no good for video tapping! So, I used a software trick and jumped a couple of extra counts into the timer to stretch it out to 60Hz. This makes video tapping look much much better.
On each roll-over of the PWM timer (16.67mS) I update the ramp profile(s). Therefore, each ramp/dwell tick is 1/60 of a second, or 60Hz. The longest profile segment (using a count of 255) will last 4.25 seconds and the shortest (using a count of 1) lasts 17ms. This gives a nice range to work within. Have a look at the attached pic from the logic analyzer. To really see the detail in the pic, open the pic in its high resolution mode. This takes a couple of extra clicks on the instructable web site. There is also a drawing of a profile shown below.
Documenting the command protocol is on my todo list. I plan to write a datasheet type of document to describe to protocol completely. I've started a datasheet for the chip - a preliminary version is on my web site now.
The source code in the 12F609 is really complicated. I am using ever last memory location! All 64 bytes have been consumed by my code. I have a whopping 32 bytes of flash left over as spare. So, I'm using 100% of the RAM and 97% of the flash. However, it amazing how much functionality you get for all that complexity.
Communication to each lamp is archived by sending eight-byte data packets. Each data packet ends with a checksum - so really, there is seven bytes of data plus a final checksum. At 9600 baud, one data packet takes just over 8 milliseconds to arrive.
The trick is to multitask while the packet of bytes is arriving. If any of the LEDs are active with a PWM signal, the output PWM must be keep updated even while receiving new packet bytes. That is the trick. It took me weeks and weeks to sort this out. I spent a huge amount of time working with my Logiport LSA trying to follow each bit. This is some of the most complicated code I have ever written. It is because the micro is just so limited. On micros that are more powerful it is easy to write loose/easy code and have the speedy micro rip through it without complaining. With the 12F609, any loose code with cost you plenty. All the micro source code is written in C except for the interrupt service routine.
Why have such large data packets you may ask. Well, because we want to have the LEDs ramp up and down on their own accord. Once a ramp profile is loaded, the LED can go off and start ramping even while receiving new commands for another LED. Each lamp has to receive and decode all data packet traffic even if the packet is not meant for it.
A LED profile consists of a start level, start dwell time, ramp rate, top level, top dwell time, ramp down rate, bottom level. See diagram attached. Wow, that is a lot for one LED. Now, multiply that times the number of LEDs. It becomes too much - I could only keep track of three LEDs with full ramp profiles. The fourth (white LED on the dev board) only has ramp from/to capability. It is a compromise. Have a look at the attached pic of a ramp profile.
The PWM signal is generated off a timer that is running at 64uS per tick. The eight bit timer rolls over every 16.38mS. This means the PWM signal is running at 61.04Hz. This is no good for video tapping! So, I used a software trick and jumped a couple of extra counts into the timer to stretch it out to 60Hz. This makes video tapping look much much better.
On each roll-over of the PWM timer (16.67mS) I update the ramp profile(s). Therefore, each ramp/dwell tick is 1/60 of a second, or 60Hz. The longest profile segment (using a count of 255) will last 4.25 seconds and the shortest (using a count of 1) lasts 17ms. This gives a nice range to work within. Have a look at the attached pic from the logic analyzer. To really see the detail in the pic, open the pic in its high resolution mode. This takes a couple of extra clicks on the instructable web site. There is also a drawing of a profile shown below.
Documenting the command protocol is on my todo list. I plan to write a datasheet type of document to describe to protocol completely. I've started a datasheet for the chip - a preliminary version is on my web site now.
Lamp Test.py4 KB| « Previous Step | Download PDFView All Steps | Next Step » |
 |
Add Comment
|
