HwData Structures » Historie » Revision 12
Revision 11 (Redmine Admin, 14.12.2021 17:54) → Revision 12/16 (Redmine Admin, 14.12.2021 18:21)
h1. HW-Data
Each Board (with MCU) should have an I2C EEPROM containung some "production" information.
The Board-Config is config information that might be inherited by production data;
e.g. max. usable LEDs; soldered transceivers. It *should* be reflected by variants but may not, at least
development samples. The software does not want to miracle information from production data.
|_.Offset|_.Type |
|0x00 | Production-Data |
|0x20 | Board-Config |
|0x40 | Config 1 |
|0x60 | Config 2 |
If EEPROM is not available, an sector in internal flash can be used.
The area within the flash should be handled by the "retain"-class from libbiwak. It
already handles header version and CRC.
"Magic"s do not make much sense. Its not supposed to be human readable.
The first 6 Bytes can be used to identify an plain PCB. Until there are not more than
0xff articles, they coud be shrinked to 4Bytes in representations.
The first 6 Bytes can be used to identify an valid article PCB.
|_.Section |_.Offset|_.Type |_.Size|_.Decription |_.Example |_.Retain Version | Comment |
|Board |0x00 | ui16 | 2 | Articles Code | 0x0020 | 4.0. | Can be printed on PCB, so no variant |
| |0x02 | ui16 | 2 | Board Code | 01 | 4.0. | Main is always main |
| |0x04 | ui8 | 1 | major version | 0 | 4.0. | |
| |0x05 | ui8 | 1 | minor version | 4 | 4.0. | |
| |0x06 | ui8 | 1 | patch version; assembly patches 1) | 0 | 4.0. | 0='X' |
| |0x07 | ui8 | 1 | Board Variant | 0 | 4.0. | Valid Solder options; The used BOM |
|Production|0x08 | ui32 | 4 | Serial number | 0001 | 4.0. | |
| |0x0C | ui8 | 1 | Production year (+2000) | 21 | 4.0. | |
| |0x0D | ui8 | 1 | Production month | 10 | 4.0. | |
| |0x0E | ui8 | 1 | Production day | 21 | 4.0. | |
| |0x0F | ui8 | 1 | Production site | 3 | 4.0. | |
|Main |0x10 | ui16 | 1 | Articles Variant | 0x0020 | 4.0. | MM Crona, No-Can |
| |0x12 | ui8 | 1 | Articles Version | 01 | 4.0. | Does not make much sense; New version new article code|
| |0x14 | ui8 | 4 | reserved | 01 | 4.0. | |
| |0x18 | Struct | 8 | Retain information; Version, counter, CRC| {-} | 4.0. | |
1) although circuit might be changed afterwards, assembly option at time of production
is relevant to relevant. To compare with errata-page.
The THe soldered parts shout match the one taged with this patch level in git.
2) Things that might be relevant for running software like used transceivers. Product specific.
Its only related to the board directly, not connected periphery.
Things like production site, version of horo-firmware etc. can be stored off-device.
Each Board (with MCU) should have an I2C EEPROM containung some "production" information.
The Board-Config is config information that might be inherited by production data;
e.g. max. usable LEDs; soldered transceivers. It *should* be reflected by variants but may not, at least
development samples. The software does not want to miracle information from production data.
|_.Offset|_.Type |
|0x00 | Production-Data |
|0x20 | Board-Config |
|0x40 | Config 1 |
|0x60 | Config 2 |
If EEPROM is not available, an sector in internal flash can be used.
The area within the flash should be handled by the "retain"-class from libbiwak. It
already handles header version and CRC.
"Magic"s do not make much sense. Its not supposed to be human readable.
The first 6 Bytes can be used to identify an plain PCB. Until there are not more than
0xff articles, they coud be shrinked to 4Bytes in representations.
The first 6 Bytes can be used to identify an valid article PCB.
|_.Section |_.Offset|_.Type |_.Size|_.Decription |_.Example |_.Retain Version | Comment |
|Board |0x00 | ui16 | 2 | Articles Code | 0x0020 | 4.0. | Can be printed on PCB, so no variant |
| |0x02 | ui16 | 2 | Board Code | 01 | 4.0. | Main is always main |
| |0x04 | ui8 | 1 | major version | 0 | 4.0. | |
| |0x05 | ui8 | 1 | minor version | 4 | 4.0. | |
| |0x06 | ui8 | 1 | patch version; assembly patches 1) | 0 | 4.0. | 0='X' |
| |0x07 | ui8 | 1 | Board Variant | 0 | 4.0. | Valid Solder options; The used BOM |
|Production|0x08 | ui32 | 4 | Serial number | 0001 | 4.0. | |
| |0x0C | ui8 | 1 | Production year (+2000) | 21 | 4.0. | |
| |0x0D | ui8 | 1 | Production month | 10 | 4.0. | |
| |0x0E | ui8 | 1 | Production day | 21 | 4.0. | |
| |0x0F | ui8 | 1 | Production site | 3 | 4.0. | |
|Main |0x10 | ui16 | 1 | Articles Variant | 0x0020 | 4.0. | MM Crona, No-Can |
| |0x12 | ui8 | 1 | Articles Version | 01 | 4.0. | Does not make much sense; New version new article code|
| |0x14 | ui8 | 4 | reserved | 01 | 4.0. | |
| |0x18 | Struct | 8 | Retain information; Version, counter, CRC| {-} | 4.0. | |
1) although circuit might be changed afterwards, assembly option at time of production
is relevant to relevant. To compare with errata-page.
The THe soldered parts shout match the one taged with this patch level in git.
2) Things that might be relevant for running software like used transceivers. Product specific.
Its only related to the board directly, not connected periphery.
Things like production site, version of horo-firmware etc. can be stored off-device.