Finally got the source code working!
Explanation & video clips here:
http://response-box.com/rgb/2009/04/...e-source-code/
JEC
Finally got the source code working!
Explanation & video clips here:
http://response-box.com/rgb/2009/04/...e-source-code/
JEC
JEC,
Any chance of offering the programmer board only and posting the pic code?
I'm not saying the $46 price isn't fair, but it's nice to DIY it whenever possible.
A mediocre person tells. A good person explains. A superior person demonstrates. A great person inspires others to see for themselves.
Click here to show/hide my display details ...
Click here to show/hide DIYC Links ...
The current board (have about 30) needs another rev to clear out a couple of airwires. I'll clean it up & post a parts list when I can.
May also replace the LCD with 3 x 7-segment LED displays. Saves $8 or so.
While your message format should work, I must point out that alternate start code 0x50 is registered to LightProcessor Ltd by the ESTA, the group in charge of DMX and related matters. http://www.esta.org/tsp/working_grou...rnateCodes.php
If you don't want to implement that in RDM, the protocol created for such things--and there are valid reasons you might not--the suggestion in the second paragraph of the link above may work for you.
More info on Manufacturer's ID field: http://www.esta.org/tsp/working_groups/CP/mfctrIDs.phpThe number of Alternate START Codes is limited to 255 possible values and many of these are already assigned or in use. Therefore, it is necessary to conserve the number of ASCs that remain for those few occasions when only an ASC will serve the purpose. Manufacturers are encouraged to obtain a two-byte Manufacturer's ID and to use it with Alternate START Code 91h to create a proprietary message in lieu of using a proprietary Alternate START Code.
I've been spending a lot of time in the RDM standard lately, including http://www.rdmprotocol.org/forums/, so I'm sensitized to such issues. I'm also pragmatic enough to know it won't matter but in a vanishingly small number of cases.
(yet another Don)
Knowing the code pretty well, i dont' think that it will take too much effort to use the 'standard'...
Good useful message, i'm sure JEC will take this on board.
stellascapes - LED lighting solutions for the Prosumer, Commercial and Entertainment Industries.
Doing pixels first since 2009 with just another megatree.
Follow us on Facebook at www.facebook.com/stellascapes
web: www.stellascapes.com
Easy enough to switch to 0x91. Thanks for the link.
Will do some digging to see what it takes to get a proper vendor ID.
Considered using RDM but decided against it because - though I have Wybron's code for the RDM stack - it's written in C. Nothing against C, but the current processor is small and slow enough as-is that the overhead of any higher-level language is just too much.
Adding a 20 MHz crystal to each pixel would totally solve the problem, but at a cost of $0.40 and a half square inch of board space.
Plus, for better or for worse there are thousands(!) of existing pixel boards out there which only support RS-485 in receive mode.
Anyway... Thanks for the advice.
What have you been doing with RDM?
Last edited by JEC; 04-04-2009 at 06:15 PM.
So far just studying the standard to see if the benefits are worth the overhead in a custom controller. Your alternate start code idea may be a better solution in many cases, especially for things like the DMX firmware for Renard boards that don't have bidirectional hardware.What have you been doing with RDM?
This started with an idea for an alternative SSR and it sorta grew. You know how it goes.
One of my other hats is advocating free/open source software, so anything I create is likely to be released that way. BTW, I understand the Wybron code is no longer free.
Bookmarks