March 3, 2007 Firmware Changes ---------------- * Added BUSY pin support back into mRGBLED firmware (on RB7). It had been removed due to space issues inthe previous firmware, but was able to be fit back in now. All other firmware supports BUSY too. * Added an enhancment to how the tiRGBLED handles commands that change multiple colors/values at the same time. Since the tiPWMs can only be addressed as an entirity, when you change a single color, all colors are updated. Same for current. While this is pretty fast, if you send a wildcard, group or range command, the process sending the change for each LED slows down processing, allows the serial buffer to fill and produces a visible "trail" effect. Consider that for a wildcard access (LED=FF), this means the PWM color data would be sent 10 times even though all LEDs are the same. The change disabled PWM updates during command parsing. Any attempt to update the PWMs is thwarted, but a dirty flag is set. After the command parsing is done for a given command, the suppressor flag is cleared and any dirty flags result in a single color and/or current update. It's no less efficiant for a single LED color change and a LOT more efficient for a multiple LED color change. * Another minor change to the tiRGBLED firmware handles initializng the PWM chips sooner than before. Previously, there was about 3/4 of a second of the uninitialized PWM chips running, but it's down to a millisecond or less now. * Added the ability to add a board to >1 board group. The exact number of additional board groups a board can belong to is limited by the controllers resources (currently, there is only the existing primary group for the RGBLED controller (no free RAM) and the mRGBLED and tiRGBLED controllers both handle 9 (primary group + 8 additionals). A new command to add groups has been added -- check the PROTOCOL.txt for more info. New Controller -------------- * Introduced new RGBLED Sequence controller. This allows downloading a number of sequences into a controller and then (optionally) disconnecting it from the computer. Then, using a simple 2 button and dial interface, allows a person to choose amongst the sequences and send a selected one to the RGBLED controller(s). You can also send a global LED on/off or select a color change mode that lets you use a dial to cycle through the LEDs hue, saturation (lightness) and brightness. The firmware in in the firmware directory and is meant for a PIC 18F2520 chip. There is a schematic and board layout for it along with documentation in the expected places. There is a Java GUI interface for programming it (though the actual sequences need to be entered into a text file the interfae will parse and send). jRGBLED changes ---------------- * Updated to allow sending commands to an RGBLED controller via/through an intermediate RGBLED Sequencer (check the box on the properties dialog) * Added an optional 5th configuration parameter to the xPL Gateways SerialPort configuration item. If present and if set to "seq", then that sets the "talk to RGBLED controller through an intermediate RGBLED Sequencer). You have to supply all other items (port, baud, inter character delay and inter command delay) in order to be able to include this. * Updated to support allowing setting the current for each LED for the TI RGBLED controller. You must visit the board properties and insure the correct controller type is selected. Then you will have a combo/drop down box for the LED current. For the RGBLED controller, you'll have 10ma and 20ma as the choices. For the mRGBLED controller, it's disabled and for the TI RGBLED controller, you'll have 64 steps in approximately 1.83ma steps. ============================================================================ January 1, 2007 Firmware Changes ------------------- * A number of fixes that could result in the serial port or controller as a whole becoming unresponsive. * Reworked how EEPROM is stored. In addition to checking each byte after it is written (previous versions was assumed it was OK), the EEPROM signature is not written until everything else is stored (to prevent a valid looking EEPROM state when the chip was powered down/restarted before writing completed) and there is a checksum byte to further insure the data is correct. While it's rare for the EEPROM data to be wrong, external circumstances (like power dips/spikes, etc) can result in corruption if they occur when the data is being written and care needs to be taken to ignore the data if invalid, lest the main RGBLED logic go off on a Nantucket sleigh ride if it references some corrupted data in memory. New Controller -------------- * Added new "tiRGBLED" driver based on the TI TLC5940 PWM chip. This firmware allows controlling up to 10 RGBLEDs, allows up to 120ma per color (tunable via software in 1.8ma steps) and requires no current limiting resistors. jRGBLED changes --------------- * Added support for the new TI based RGBLED firmware to the board properties * Added an option to log all commands being sent to the controller on the console. This means you have to start jRGBLED from a command prompt/shell prompt and for windows users, you have to use the "java", NOT "javaw" command to have it display. The option is available in File->Properties. * Added a new "board exerciser" option to the Board menu. This will randomly send most relevant commands to a controller board to test the boards stability. The LED/light patterns themselves are not important, the important part is that the board continues to respond (i.e. no lockup) and that the error light doesn't come on (insure the Board->Properties settings match your board before doing this). Hardware Changes ---------------- * The CAD files and images of the schematic and board layout for creating the new TLC5940 based RGBLED controller are available. From an assembly standpoint, the TLC5940 is a standard DIP package device, so no SMD soldering is required. The TLC5940 has adjustable constant current outputs, so dropping resistors to the LEDs are not needed. The board also has provisions for an optional on-board power regulator and more decoupling capacitors for running the device at the end of a power line (including space for a large, high density electrolytic). Support for low-resistance RS232 interface or a TTL/SPI synchronous interface are provided. * All hardware files (CAD files, schematic and board images) are now in the hardware subdirectory of the distribution (they used to be in a cad directory, but that isn't a helpful name for a lot of folks). ============================================================================ July 25, 2006 Firmware Changes ---------------- * Fixed a problem initializing the serial port for the 16F88 chip (the 16F87 was fine, but an aspect of the 88's A/D converter that I had not considered needed to be configured) ============================================================================ July 17, 2006 Firmware Changes ---------------- * There was a problem with the RGBLED (not the mRGBLED) firmware not correctly installing a board group definition. This has been fixed. * There was a problem with the mRGBLED allowing any value as a board group value. This has been fixed. If the new board group value is not between 0x00 and 0x0e, it is ignored. The RGBLED firmware already had this test. ============================================================================= July 13, 2006 jRGBLED Changes --------------- * Added the ability to flag (via the Board->Properties menu) if the board is a RGBLED or mRGBLED board. Selecting the correct board will insure only the correct LEDs can be edited and will not send commands to the board for LEDs it does not have (when doing an "Upload all LEDs" command). * Corrected a bug that would sometimes leave a animation color step hex color field colored as if there were an error even after the error was corrected. * Added the ability to define more color steps for each LED (up to 32 steps, which is the most the controller can handle). Firmware Changes ---------------- * Fixed a problem whereby the serial command buffer could become full which disabled serial interrupts, but the serial interrupt code would then stop running and a terminating character for a command would be lost. Result is the unit would stop responding to serial commands until power cycled. * Change the serial handler for the mRGBLED firmware to be interrupt driven again. Previously, it was polled and when the PIC was busy, it was easy to overrun the hardware. This required putting delays after every few characters. With this change, the chip should be able to run at 9600 baud with no delays and 19200 with a 1ms delay and 38400 a 2ms delay between commands (and really, you only need that if sending a lot of commands to give the chip a process to empty some of the command queue -- if sending less than 7 commands (roughly), you really don't even need that delay). * Reworked the mRGBLED PWM code to take less time, resulting in a sustained refresh rate of 61hz (i.e. no flickering). The result is substantantially more solid colors at lower intensities and better, flicker free long duration washes and fades. * The error LED on the RGBLED/mRGBLED board would come on whenever an improperly addressed LED was referenced. This was fine when directly addressing the board, but if sending a command to a wildcard board ID out onto a line with mixed mRGBLED and RGBLED modules, the mRGBLED module would show an error if any LED over 02 was addressed and would not process ranges and such if anypart of the was out of range. This made integration of mRGBLED and RGBLED units difficult because for broadcast operations, you had to break them up so the mRGBLED would process the parts it needed. Now, if the target of a command is a board group or wildcard, then invalid LEDs will not cause an error that stops. Instead, all the possible, valid LEDs that match the command will be processed and the invalid ones will be ignored with no error condition. NOTE: When the board is addressed directly (i.e no wildcard and no board group), the LED or LED range must be valid or the error LED is lit and the entire command is discarded (not even potentially valid LEDs are processed). Consider this: You send a command to Board ID FF to turn all LEDs from 0 to 8 off. Or "#FF0080" (a range). You send this via a serial port with both RGBLED and mRGBLED controllers. Old Behaviour: RGBLED board processed it OK mRGBLED board saw the "8", flagged it as an error (lights error LED) and discarded the command. So no LEDs on the mRGBLED board would be turned off. New Behaviour: RGBLED board processed it OK mRGBLED board processed the valid LEDs (00-02) and ignored the values above that. So no error LED and the LEDs on the mRGBLED board are turned off. This behavior ONLY applies to broadcast/wildcard and group board addressing. Addressing a specific board will still result in the command being dropped if any part of the LED specification in the command is invalid/out of range. ============================================================================ June 12, 2006 Firmware Changes (affects RGBLED and mRGBLED): * Found cases where there could be internal call stack overflows and fixed them. * Changing a board ID no longer automatically saves that ID to EEPROM. You need to issue a "save/preserve" command to make that permanent (along with all other settings). * Each board can belong to a board group now. There are 15 groups possible. A board can be assigned to any one group or none (the default). When commands are issued, they can be issued to a specific board (as before), to all boards via a wildcard (as before) or to all boards or a specific group. Check out the F5 and F6 commands for details. * Each LED on a board can belong to a LED group. Note that LED groups and board groups are not at all related. There are 15 LED groups possible. An LED can be assigned to any one group or none (the default). When issuing LED commands, they can be issued to a specific LED (as before), to all LEDs on the addressed board(s) via a wildcard (as before) or to all LEDs of a specific group on the board. Check out the 15 and 16 commands for details. Note that LED groups are board specific. So group "0" on board "00" has no connection/relation/etc to group "0" on board "01". You can, of course, choose to treat your LED groups as global, but that is just how you choose to allocate groups and configure your LEDs. * LED oriented commands can now take a range for the LED to affect. Since LEDs are addressed from 0x00 to 0x0C, that leaves the top nibble free. If the top nibble is != 0 and < F, then the low nibble is the starting LED and the high nibble is the end. So an LED spec of 0x92 would mean the command applies to all LEDs between and including LED 0x02 and 0x09. * Fixed a bug in the mRGBLED driver that would treat slaved LEDs differently than the RGBLED driver would. In particular, when an LED is slaved to a master, the only exposed characteristic of the slave is it's current setting. All other settings (on/off, level, etc) come from the master. The mRGBLED was properly getting a slaves level from it's master, but was using the slaves on/off status, not the master. That has been fixed so that the slaves on/off status correctly comes from the master now (like the RGBLED does). Clarification on Hardware: For the standard RGBLED board, use of the 6966 or 6967 PWM chip is possible. Both chips are identifal with the exception of the programming of the DOUT/OSC pin (6966 defaults it as DOUT, 6967 defaults as OSC). The RGBLED firmware correctly initialize the pin to DOUT regardless of the chip and they are otherwise electrically identical. So selection should really just be based on which is easy/quicker/cheaper to obtain. This issue does not apply to the mRGBLED hardware. jRGBLED API: * Updated API to include setLEDGroup, clearLEDGroup, setBoardGroup, clearBoardGroup and animation color adding routines to accept a color of null (meaning "current" color) as well as setBoarCommonAnode and setBoardCommonCathod commands. jRGBLED xPL Gateway: * Added the ability to address boards by board ID (0-254), all boards (All) or a board group (Gx where x is the board group # 0 to 14) * Added the ability to address leds by led ID (0-12), all LEDs (All), a range of LEDs (low-high, 3-9, for example) or an LED group (Gx where x is the group # 0 to 14). * Added the SET_LED_GROUP, CLEAR_LED_GROUP, SET_BOARD_GROUP and CLEAR_BOARD_GROUP commands. The SET_xxx_GROUP commands add a new NEW_GROUP= to specify which group, 0-14 to add the led/board to. * Added the ability to include COLOR=CURRENT on the add animation color and define animation commands. * Added ability to set mRGBLED board to common cathode or common anode output mode * Updated the xPL plugin (used by DCL and xPLHAL) to allow LEDs and Boards to be address via ALL, a number, a numeric range (for LEDs) or a group (Gx) and include new commands and options. jRGBLED GUI Configurator * You can now assign an LED to an LED group via the GUI * The Board->Assign Board ID menu option has been reworked into a Board->Board Properties dialog that lets you change the board ID, the board group and the anode/cathode drive (mRGBLED only for the last one). NOTE: Do keep in that changing the board ID no longer auto-stores that ID in EEPROM. You have to issue a "PRESERVE BOARD" command to make the board ID stick (like anything else) =============================================================================== January 31, 2006 Firmware Changes: * Found a bug that could lock the unit up after receiving certain kinds of invalid commands and/or text. This wasn't a problem as long as all commands were valid, but some invalid ones would break it. * There is now a built-in lamp test in the firmware. When the firmware is first burned into the PIC, a preset light test pattern is stored in the EEPROM and when the chip powers up, it'll run it. It stays until you program a different pattern or configuration into the EEPROM. This lets you immediately test the boards when building without having to hook a PC up first. ============================================================================= November 1, 2005 Firmware Changes: * Added the ability to do a one-shot animation. That is, the animation runs when enabled, but after it gets to the last step, it leaves the last step color installed and stops. * Altered the way disabling an animation works. In the past, disabling an animation caused the first color in the animation to be installed for the LED. Now, whatever color is on the LED at the time the animation is disabled is what is left on the LED. * Added the ability to automatically release animation colors for an LED when it is implicitly or explicitly disabled. This works well with the one-shot color change option, but can be used for other things as well. * Added command to add an animation step using the LEDs current color as the color to add as a step. Good for "starting" new animation without abrupt color shifts. jRGBLED: Change to allow setting new options to do one shot animations and auto-released colors xPL RGBLED Driver: Added new new ANIMATION_REPEATS and AUTO_RELEASE_COLORS options to RGBLED xPL commands. Updated plugin is available. ============================================================================== September 11, 2005 Firmware and Hardware Change * Createed alternate PWM driver using only the chip itself. This can be built for a 16F87 or 88 (lower power or normal 5volt) and can drive up to 3 RGBLEDs. The resultant pinout is different (be careful) and you have to use the appropriate current limiting resistors on each leg of the RGB (don't try to regulate on the common lead -- that will result in uneven LED illumination). This version can be set to use common anode OR common cathode outputs (one setting for the entire device). If you only need to control 1-3 RGB LEDs, this version will require a lot less hardware (no PWM chips, no 5->3.3 power regulator (unless you use the LF chip and only have a 5V power supply)). As pointed out above, the downside is you have to calculate and use current limiting resistors, but this isn't too tough. ============================================================================== August 22, 2005 Firmware Changes: * There is a new binary command format available. This is likely and easier format to use when interfacing the board with another small-processor controller as it reduce the need to reformat values into ASCII hex before sending. You can use either binary or standard ASCII hex commands interchangably over either interface (SPI or RS232), though SPI is the more likely one with this format. Complete details in the included protocol.txt file. * The logic that preserves settings to EEPROM now disables interrupts while doing that. Previously, interrupts were left alone and an interrupt while writing the EEPROM could result in corrupted EEPROM. * In addition to setting the BUSY flag high whenever the serial command buffer is nearly full, it is now also set high whenever interrupts are disabled for more than a few instructions (more than about 100 microseconds). This is rare and generally very short (with the exception of when preserving the settings to EEPROM which can disable interrupts for a second or two), but is important to properly throttling serial data and preventing overruns. Note: Even when interrupts are disabled, the UART will still allow reception of up to 2 characters/bytes before it's internal buffer will overflow. So you have a little bit of margin in reacting to a BUSY flag being set. When interrupts are again enabled, the BUSY flag is then set to reflect the fullness of the internal serial buffer (if near capacity, it'll remain on/high. If safely under capacity, it'll be set low). Software: * jRGBLED no longer allows PWM count setting -- all PWMs are now always enabled/allowed (which tracks with removing the configurable number of PWMs from the PIC firmare). * jRGBLED now allows direct editing of the animation color steps values. Previously, you could see the color values (the hex equivilents of the colors), but could only change them by clicking on the related color swatch and using the color chooser (which still works). If you know the value you want, this can be faster than using the color chooser. ============================================================================ August 8th, 2005 Hardware * Board has better labelling on the connectors than before and bigger ground-plane busses Software * jRGBLED changed the "Reset/Reboot Board" menu option to be just "Reboot Board" * Added a "Upload LED" option to the LED menu (same as the Upload LED Now button) * jRGBLED distribution is now packaged with the java source code * jRGBLED also acts as a xPL4Java xPL interface module ============================================================================ August 4th, 2005 Hardware * The board layout has been compacted, yielding a new board size of 2.1" by 3.8" (previous size was 2.6" by 4.1"). ============================================================================ July 31, 2005 Firmware Changes: * Much better performance in keeping up with serial commands. See the "Pacing" section of protocol.txt for more details on timing. * Multi-command serial buffering helps prevent corrupt/dropped commands * Ability to animate in 1/100th of a second (as well as 1/10 and 1 second increments as before). * New "busy" line that can be used as a hardware flow control/pacing, if needed (set when buffer is nearly full and CPU is falling behind, cleared when the buffer space opens up. * CPU always allows 4 PWMs now -- no more jumpers needed to set number of PWMs. * The 3x series macro commands were removed to make space for the new improved buffering, performance and 1/100th second animation features * Bug in restoring power up state from EEPROM fixed. * New "Reboot" command that reinitializes all hardware on board to power up conditions (including re-reading baud rate, re-initializing PWM hardware, re-reading LED state from EEPROM, etc). jRGBLED configuration tool * Properly save and restore com port and baud rate for boardset (used to be saved, but never re-loaded) * Support for 1/100th second LED animation * New "Reboot" option in Board menu * "Initialize" option in Board menu renamed to "Clear" * Better indication of modified configuration state (the MODIFIED flag is set for all changes and now is cleared when you actually do save). Hardware * Jumpers for PWM count have been removed. If you use the older board with jumpers, be sure to remove them as the pins they connected to will be outputs (not inputs) with the new firmware. * The 13th LED header has been moved down slitghtly to better fit board * The Busy and Error line are now brought out to the Sync/SPI header * The Busy line is now brought out to the ASYNC header * The Async chip now has option for 4 caps to allow RS232 CTS line * The Sync data and clock line now have option for 10k pull-down resistors to terminator the SPI/Sync bus. * Holes for the power regularot are now much larger =========================================================================== June 28th, 2005 * Initial release of firmware and board schematic