CODEWITHSUNDEEP
embeddedversioning
supercat
supercat

Reputation: 81169

Handling version numbers for remotely-upgradeable embedded systems

I am presently working on a family of embedded products that will phone into a PC to exchange information. At present, different members of the family store and exchange information in different ways, but any particular type of unit will only store and exchange information in a single format. The PC is capable of supplying any remote unit with new firmware, which will be loaded the next time that remote unit is rebooted (the PC can request reboots).

At present, when a unit phones in, it will report a unit type (string), version number (increments with each build) and build date; the PC will look up the unit type in a database and check whether the database firmware is newer than the one in the unit. If so, it will load the database firmware into the unit and ask it to reboot and call back (rebooting will drop the connection).

This scheme works, but it seems a little hokey. It's probably desirable to forbid the use of firmware versions prior to certain bug fixes, but I'm not sure how that should best be coded. Should each build of the application have a hard-coded list of minimum acceptable firmware revs for each hardware type? If a newer firmware rev adds a new memory field or style of communication packet, how should interoperability best be handled? Saying "If FirmwareRev > 1.23458 Then Mem(29)=BeeperFrequency Else Mem(29)=0" seems rather crude.

One idea I had would be for the firmware rev description to contain a bitmask of various features, but I had no idea how to sensibly allocate such bits so as to avoid either using too many bits to specify features that end up always going together (and thus running out of bits) or using one bit to control features that end up later being separated.

Has anyone else dealt with such issues? How are they best resolved?

Upvotes: 1

Views: 264

Answers (1)

Rex Logan
Rex Logan

Reputation: 27116

I would just have the units report their MAC address which is guaranteed to be unique along with your other information and then just keep a small database on the server and let it manage the upgrade decision. You might want to downgrade as well as upgrade so I would keep the smarts on the server.

Upvotes: 1

Related Questions