E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   RDM Firmware Uploads (http://www.rdmprotocol.org/forums/showthread.php?t=1153)

terminal January 12th, 2013 02:49 AM

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?

sblair January 12th, 2013 09:20 PM

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.


terminal January 12th, 2013 11:09 PM

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.

sblair January 13th, 2013 02:58 AM

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.

terminal January 13th, 2013 09:30 AM

Thank you ...Im realized that turning to the region from 8000 other manufacturers have to be careful.

sblair January 13th, 2013 08:21 PM

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.

terminal January 13th, 2013 09:07 PM

When the team standardized all software manufacturers know that it could not be applied so as not to spoil the device.

sblair January 13th, 2013 09:44 PM

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.

terminal January 14th, 2013 05:35 AM

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 January 14th, 2013 05:54 AM

I worry that mistakenly sent a team with my software spoil someone else's device.

terminal January 14th, 2013 06:07 AM

You can declare outside the public PID is in the range of 8000. But to manufacturers of it sought to adhere to.

prwatE120 July 28th, 2014 10:31 PM

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

este_ August 1st, 2014 12:27 PM

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

Any idea when this might happen?

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

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