HwData Structures » Historie » Revision 14
Revision 13 (Maximilian Seesslen, 15.12.2021 11:15) → Revision 14/16 (Redmine Admin, 15.12.2021 18:05)
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 5 Bytes after magic 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 7 Bytes after magic can be used to identify an valid article PCB.
|_.Section |_.Offset|_.Type |_.Size|_.Decription |_.Example |_.Retain Version | Comment |
|Board |0x00 | ui8 | 1 | Magic 'B' / 0x42 / 66 | 'B' | 4.0. | Check content with GDB |
| |0x01 | ui16 | 2 | Articles Code | 0x0020 | 4.0. | Can be printed on PCB, so no variant |
| |0x03 | ui8 | 1 | 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 compare with errata-page.
The soldered parts shout match the one taged with this patch level in git.
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 5 Bytes after magic 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 7 Bytes after magic can be used to identify an valid article PCB.
|_.Section |_.Offset|_.Type |_.Size|_.Decription |_.Example |_.Retain Version | Comment |
|Board |0x00 | ui8 | 1 | Magic 'B' / 0x42 / 66 | 'B' | 4.0. | Check content with GDB |
| |0x01 | ui16 | 2 | Articles Code | 0x0020 | 4.0. | Can be printed on PCB, so no variant |
| |0x03 | ui8 | 1 | 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 compare with errata-page.
The soldered parts shout match the one taged with this patch level in git.
Things like production site, version of horo-firmware etc. can be stored off-device.