|
RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product. |
|
Thread Tools | Search this Thread | Display Modes |
June 23rd, 2009 | #1 |
Junior Member
Join Date: Jun 2009
Posts: 5
|
Firmware download
I was wondering of there is, or will be, a standard way to download firmware into a device using the RDM protocol? It would be nice to have a standard way that can be implemented in the controller so it can be used for all devices of any manufacture (like in the ArtNet protocol).
Regards, Kurt |
June 23rd, 2009 | #2 |
Administrator
|
Kurt,
At this point it doesn't look like there will likely be a standardized method of doing this, at least not anytime on the horizon. We spent a lot of effort on this and had several draft versions but never reached concensus. The issue was that there are too many different architectures out there and to make a single implementation that was robust enough to be reliable and not risk leaving a product doorstopped with nothing other than boot code made the process a bit cumbersome for some. Ultimately what happened was that everyone adopted their own manufacturer-specific way of doing it and as a result interest was lost by most involved with it as they then had their own solution. Firmware uploads are probably best left being a manufacturer-specific implementation that way there isn't the risk of someones bad implementation on the controller side erasing the flash and leaving a product stuck in boot without completing the upgrade process.
__________________
Scott M. Blair RDM Protocol Forums Admin |
June 23rd, 2009 | #3 |
Junior Member
Join Date: Jun 2009
Posts: 5
|
Scott,
Thanks for the reply. I understand the arguments and the difficulties, but we, as developers, make it our customers even more difficult. Now they must use different and special software to perform the update. When we would choose a good microprocessor, and this is now a lot easier and cheaper then 5 years ago, we could solve the problem relative easy. So it may be a good idea to place the issue back on the wish list and start thinking again, with the lasted technology in mind, to solve the problem. Maybe the solution will not be the fasted possible or the most elegant, but you can make it very robust without a problem. With the current flash, eeprom, ram sizes, there is also no more need for a very restricted bootloader. This standard feature can then be implemented in future products, so that there will come no more(or less) manufacture specific solutions and our customers can be better off. In the mean time I will also create my own solution. Regards, Kurt |
June 23rd, 2009 | #4 |
Administrator
|
Kurt,
The issue is that it takes people that are interested in solving it to attend and participate in the meetings to develop it. It is not a trival process. Right now there is not anyone that is interested in leading or investing effort in that project, that is why it died.
__________________
Scott M. Blair RDM Protocol Forums Admin |
June 25th, 2009 | #5 |
Junior Member
Join Date: Feb 2009
Posts: 13
|
microFTP
I agree the a firmware download addition to RDM would be very difficult to implement in a way that would useful to all user's with the different hardware requirements of all the different manufactures. I think that a microFTP type addition could receive more support. It could be used to allow the storage/retrieval of a file containing the fixture personality (new XML fixture personality standard ?) and of course a firmware image could be downloaded and then a manufacturer specific PID used to cause the update from the loaded file.
|
June 28th, 2009 | #6 |
Administrator
|
We also discussed and explored doing a TFTP style basic implementation but there wasn't enough interest from people in working on it, so that is why we ultimately shelved it for now.
__________________
Scott M. Blair RDM Protocol Forums Admin |
November 9th, 2009 | #7 |
Junior Member
Join Date: Sep 2009
Posts: 2
|
Hi all,
Could anyone tell me about a way to implement a remote software upgrade? I mean, do I have to keep a kind of RDM-like frame, with a 0xCC startcode? I guess it could be harmful for other devices on the bus... Then what are your advices? Is there any prefered startcode or way to achieve it? Best regards, Francois. |
November 27th, 2009 | #8 |
Administrator
|
Francois,
I would highly suggest implementing as using manufacuturer-specific PID's within RDM. See Section 6.2.10.2 in RDM. Using the standard RDM frame and defining your own messages within that you can implement firmware uploads. The advantage of doing it within RDM packets and start code is that you can then take advantage of all the other infrastructure that exists out there such as RDM splitters. Scott
__________________
Scott M. Blair RDM Protocol Forums Admin |
November 29th, 2009 | #9 |
Junior Member
Join Date: Sep 2009
Posts: 2
|
Scott,
Thanks for your answer. I agree this is probably the smartest way. I can't believe I haven't thought of it! Francois |
December 8th, 2009 | #10 |
Administrator
|
Francois,
I just have the benefit of living and breathing this for the last 10 years now is all
__________________
Scott M. Blair RDM Protocol Forums Admin |
December 12th, 2019 | #11 |
Member
Join Date: Nov 2015
Posts: 31
|
Hello rdmprotocol..
Long time, no post.. probably because our RDM implementation seems to be mostly ok.. in large part to the help I've received here. many continued thanks.. as always!. I saw this thread and am interested in any information anyone can provide about firmware updating over RDM.. Has there been any activity worth mentioning since this last post 10 years ago?! Thanks in advance. Also, is there any plan for a Dallas Plugfest in the next year? It's been a while and it'd probably be good to go again... Thanks! dougj |
December 13th, 2019 | #12 |
Task Group Member
Join Date: Aug 2008
Posts: 379
|
The E1.37-4 document for file transfer is moving, although I've lost track of exactly where it is. It's been through at least one public review. There will be a plugfest in 2020. The plugfest is often held in Dallas in July, but the July 2020 meetings are in NYC. I suspect the next plugfest will be October 2020. It's not been formally scheduled yet, so watch the TSP meeting schedule. Come visit us, it'd be nice to see you again.
|
Bookmarks |
Thread Tools | Search this Thread |
Display Modes | |
|
|