Closed mondalaci closed 7 years ago
@mondalaci
dataModelVersion
be in the hardware configuration?signature
also be present in both configuration?hasBacklighting
and isIso
are integers instead of booleans?dataModelVersion
should be in both configurations.signature
should only be present in the hardware configuration.hasBacklighting
and isIso
should be booleans. I don't know why I used integers above.@mondalaci Question first was "Why..."?
The idea is to version the hardware configuration and the user configuration separately. The dataModelVersion
of the hardware configuration should change very rarely.
Oh, so it is a different version number, just the names are identical. Okay, thanks for the information.
Probably too late, but ISTR reading that the typical jumper in robotic manufacturing is a 0ohm resistor.
@TorC8 A 0 ohm resistor is a possibility I considered but I decided that we should rather not make different PCB versions just because of this. Setting up the flash configuration area in the factory is a more flexible approach that uses a single PCB version.
Given the issues I encountered, it'd make sense to split the configuration. There would be a hardware configuration and a user configuration.
The hardware configuration would contain all the hardware specific data. This information is strongly tied to the hardware. It'd be uploaded in the factory and not expected to be modified later. It would contain the following fields:
The user configuration would be pretty much the same as our existing configuration without the above fields.
dataModelVersion
will be present in both the hardware configuration and user configuration.The background story of this change is that originally, I wanted to feature solder jumpers on the UHK PCB to make the UHK able to detect whether it has an ISO layout or whether it has LEDs. This is how solder jumpers look like:
But as it turns out, solder jumpers are rather cumbersome from a manufacturing standpoint, so it'd be a lot nicer solution to store such information in a dedicated page of the EEPROM, so it won't be accidentally overwritten. This is why the separate hardware configuration makes sense, which will reside in the first 64 byte page of the EEPROM and won't be affected when updating the user configuration.