Bureaucrats, dave_user, Administrators
8,226
edits
Changes
→DAVE Embedded Systems' hardware implementation
{{InfoBoxTop}}
{{AppliesToAXEL Lite TN}}
{{AppliesToAXEL ULite TN}}
{{AppliesTo SBC Lynx TN}}
{{AppliesTo ORCA TN}}
{{AppliesTo ORCA SBC TN}}
{{AppliesTo MITO 8M Mini TN}}
{{AppliesTo MITO 8M Nano TN}}
{{AppliesToETRA TN}}
{{AppliesTo ETRA SBC TN}}
{{AppliesToBORA TN}}
{{AppliesToBORA Lite TN}}
{{Applies To Diva}}
{{InfoBoxBottom}}
# I2C Eeprom
## example: DIVA family processor (AM335x) or BORA Lite processor (ZYNQ) implements ConfigID using I2C Eeprom when NOR SPI is not present (module boots from NAND or SD)
## DIVA and BORA Lite use the first 32bytes on I2C EPROM to store ConfigID (and its CRC32), UniqueID (and its CRC32)
# 1-wire
## example: latest XELKAXEL Lite, DIVELK, BELK Carrier Boards AXEL ULite and BORA/BORA Xpress/BORA Lite Evaluation Kits implement CB ConfigID using the onboard 1-wire device (DS2431)
==== Software implementation ====
</pre>
=== A real case example of Config ID ConfigID benefit ===The Config ID ConfigID benefit is clear when:
* there is a number of products deployed on the field
* the products deployed on the field needs a SW update
The ideal scenario is that all products are equal and there are no differences on the Bill Of Material (BOM):<gallery caption="All products have the same BOM with a single Config ID">
File:Smartphone-icon.png|Config ID ConfigID AFile:Smartphone-icon.png|Config ID ConfigID AFile:Smartphone-icon.png|Config ID ConfigID AFile:Smartphone-icon.png|Config ID ConfigID AFile:Smartphone-icon.png|Config ID ConfigID AFile:Smartphone-icon.png|Config ID ConfigID A
</gallery>In this case there are no problems to deploy a new SW update on the field: all products have the <u>'''same'''</u> HW configuration, then the '''<u>same</u>''' SW configuration.
force to have an on-the-field different version of product (with same functionalities but with different HW configuration) which doesn't permit to realize what proposed in the ideal case.
{{ImportantMessage|text=The usageof usage of the ConfigID technique, allows the running SW to identify the underlying HW configuration and automatically adapt the BSP (i.e. the driver layer) to properly use the HW subsystems: this, maintaining the overall product geature features identical from to the final User point-of-view.}} <gallery caption="All products are similar BUT there are different Config ID between the 2 product versions">File:Smartphone-icon.png|Config ID ConfigID AFile:Smartphone-icon.png|Config ID ConfigID AFile:Smartphone-icon-2.png|Config ID ConfigID BFile:Smartphone-icon-2.png|Config ID ConfigID BFile:Smartphone-icon.png|Config ID ConfigID AFile:Smartphone-icon-2.png|Config ID ConfigID B
</gallery>With a scenario, like the one described above, if you would like to update the SW you need to implement a strategy for understanding what platform version is going to be updated. The Config ID is used exactly for this goal.
The Config ID ConfigID provides to the software update routine the information on which product version is so the update can be adapted to the exact product version.
In this way, you can distribute one single version of the software update which will automatically adapt itself to the currently running platform.
==== How to handle After Sales with Config ID ====
One of the mos common questions about Config ID is how to handle the Config ID issue. Below is described with an example how to handle it.