E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Reply
 
Thread Tools Search this Thread Display Modes
Old January 12th, 2013   #1
terminal
Junior Member
 
Join Date: Jan 2013
Posts: 7
Lightbulb RDM Firmware Uploads

Hello!I want to make a function via software update protocol RDM.
I can not find the documentation to do this.
Tell me how to implement it within the RDM protocol?
terminal is offline   Reply With Quote
Old January 12th, 2013   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

There is not a standard method for doing this as there are a lot of factors that vary from one architecture to another that have made creating a standardized method difficult.

There are many people that have implemented this using manufacturer-specific PIDs in RDM. There may be some other folks on here that can share their method of doing it.

Here's a basic process in general though.

You need a PID to PREPARE_FOR_CODE. This PID will tell the target device to erase it's flash or whatever it may need to do to expect a file transfer to occur.

You then need 1 or more PID's to handle block transfer of your data. You basically split your file transfer up into whatever block size is convienent for your device within the payload constraints allowed by RDM. Generally you will want a field to indicate what the Block # or address is in the packet along with the data. After sending the block it is generally a good idea to send a command to verify the Block was correctly received or allow the device to respond with a request to resend the block. This way you know that blocks of data are not getting lost and the device can indicate a failure has occurred.

An Upload Complete PID. This PID is used to indicate that you have completed the transfer and for the device to complete the programming process. It is also a good idea in this packet to include a robust checksum, like a CRC, of the code you have uploaded that the device can then verify whether the upload was valid or whether errors occurred in the transfer.

Hope this helps. Feel free to ask more questions as needed.

Scott
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 12th, 2013   #3
terminal
Junior Member
 
Join Date: Jan 2013
Posts: 7
Default

As I understood the PID should be from 8000 to FFFF. But do not get that other manufacturers use similar PID erase my Software obespechenie. Is it possible to PID in the range 0-7FFF to start the process. I apologize if the interpreter translated incorrectly.
terminal is offline   Reply With Quote
Old January 13th, 2013   #4
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

PID's in the 0-0x7FFF range are reserved for PID's that are publicly defined in one of the standards which is a very long process. The range from 0x8000 up as you correctly identified is for manufacturer-specific implementations.

Controllers SHOULD query the device for what PID's are supported in the manufacturer-specific range first, but as you identified another controller could send this PID still which would erase your flash.

There are a few methods to protect against this. First off, the block transfer PID's can NACK unless they have received the PREPARE PID first that I had mentioned.

That just leaves you to protect the PREPARE PID which might be what triggers the Flash erase in your system. The first way to protect this is for the target device to ignore this PID unless the Source Address is your own Manufacturer ID. The other way is to include like a pre-defined 16 character string in the Parameter Data for that PID that acts as a key to unlock it. If the string does not exactly match what you are expecting then the PID gets NACK'd.

That is basically how most of us implement it ourselves to protect against accidental triggering.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 13th, 2013   #5
terminal
Junior Member
 
Join Date: Jan 2013
Posts: 7
Default

Thank you ...Im realized that turning to the region from 8000 other manufacturers have to be careful.
terminal is offline   Reply With Quote
Old January 13th, 2013   #6
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

When it comes to erasing the flash, you would have the same concerns even in the 0-7FFF range as it would be easy for any device to send a command that could erase your flash.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 13th, 2013   #7
terminal
Junior Member
 
Join Date: Jan 2013
Posts: 7
Default

When the team standardized all software manufacturers know that it could not be applied so as not to spoil the device.
terminal is offline   Reply With Quote
Old January 13th, 2013   #8
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

For a well implemented controller, yes. But there are many controllers that allow any PID to be sent. So a user not knowing could easily send that PID without having a way to recover the device.

This is one of the reasons why firmware uploading is still best done as manufacturer-specific PIDs where measures can be put in place to protect the device.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 14th, 2013   #9
terminal
Junior Member
 
Join Date: Jan 2013
Posts: 7
Default

I was referring to the start of the PID, a kind of key. Without a change is not possible to change the software. All producers will know the PID. Castle PID. If the door is closed it is possible to work with the area 8000 is safe. Otherwise, I think there may be problems in the future.
terminal is offline   Reply With Quote
Old January 14th, 2013   #10
terminal
Junior Member
 
Join Date: Jan 2013
Posts: 7
Default

I worry that mistakenly sent a team with my software spoil someone else's device.
terminal is offline   Reply With Quote
Old January 14th, 2013   #11
terminal
Junior Member
 
Join Date: Jan 2013
Posts: 7
Default

You can declare outside the public PID is in the range of 8000. But to manufacturers of it sought to adhere to.
terminal is offline   Reply With Quote
Old July 28th, 2014   #12
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

The PLASA Technical Standards Council has just accepted a new project BSR E1.37-4 which has a working title of "Remote Device Management over DMX512 Networks File Transfer Control with Firmware Upload capabilities"

We would welcome your further input when the initial draft is released for Public Review.

Peter Willis
prwatE120 is offline   Reply With Quote
Old August 1st, 2014   #13
este_
Junior Member
 
Join Date: Jan 2010
Location: Germany
Posts: 24
Question

"We would welcome your further input when the initial draft is released for Public Review."

Any idea when this might happen?
este_ is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Firmware download kster RDM General Implementation Discussion 11 December 13th, 2019 01:53 PM


All times are GMT -6. The time now is 05:56 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.