mzieg
commented
2 months ago @mzieg I didn't understand your comment about
make Model char[32]
This sounded like a repartitioning of the EEPROM i.e. expand Model to take up bytes left fro Product Configuration?
What I was thinking was, keep the current Model: [____] field we already have on the EEPROM Editor.
However, don't treat it as a 1-to-1 mapping with EEPROM.model. When populating lineEdit_ee_model, load it from SpectrometerSettings.full_model(). And when the user writes the EEPROM, take the current value of lineEdit_ee_model and write the first 16 bytes to eeprom.model, and any remaining bytes to eeprom.product_configuration.
So that way, yes the model name would be technically split across two non-contiguous blocks on different EEPROM pages, but as far as ENLIGHTEN was concerned (even at the EEPROMEditor which nominally shows the "physical structure" of the EEPROM), it would be treated as a single logical char[32].
One can argue that ENLIGHTEN doesn't need to structure this page after the physical structure of the EEPROM in the first place, and should be more "logically" ordered to be sensible to end-users. I was trying to also use it as a "debugging" page for programmers to help them understand ENG-0034. For the most part, I think it meets both functions. However, the way it handles long model names, like (for instance) 785XSB-F13-A-ILPSM-20-OEM+XYZ, is non-intuitive even to me :-(
Not sure I fully understood the request from the issue, but Product Configuration is definitely gone from the EEPROM Editor.
This is a purely aesthetic change in the sense that the data is still stored there, it's just not being displayed.
@mzieg I didn't understand your comment about
This sounded like a repartitioning of the EEPROM i.e. expand Model to take up bytes left fro Product Configuration?