Identification of microcontroller and AYAB hardware type/version

[dl1com]

Additionally to the firmware version, it might be useful to be able to identify on which hardware the firmware is running.

• Information which would have to be "stored" directly in hardware (i.e. hardware revision) and read somehow by the firmware. Currently there is no hardware which supplies such information, so this might be a requirement for the upcoming hardware [WIP] Requirements for Next-Gen Hardware ayab-hardware#20
• Information which can be obtained during the build process, i.e. microcontroller for which the firmware is compiled for, so this information could be stored in the firmware (i.e. Arduino UNO / ESP32).

The API would have to get extended to add that info in the version check.

[oskay]

This is a tricky issue.

Compiling the hardware revision directly into the firmware leads to lots of firmware versions; not great.

On some platforms, configuration information can be stored in nonvolatile "EEPROM". This is good, but it can be overwritten when updating firmware. If this approach is used, it's essential that the default value when updating firmware is "no hardware model assigned", rather than some particular hardware version.

[t0mpr1c3]

There is other hardware information you might want to save. In the Discord hardware channel, someone suggested calibrating the hall sensor trigger levels as a workaround for 3V/5V VCC levels.

[oskay]

Would measuring Vcc work for that?

[t0mpr1c3]

Yes, it's certainly not the only solution. I'm struggling to remember the context but I think there was also some discussion about the trigger levels possibly varying across machines, e.g. for KH270 which has barely been tested up until now.

[VIPQualityPost]

On the ESP32 there is an OTP with 1.7kbit reserved for user data. I don't know if this helps at all with making sense of earlier shield/interface revisions, but that would be a fine place to include the hardware rev info.
We can use the pre-build script by @dl1com to also embed information about the build into the OTP so that hardware rev, date, and current firmware release at time of first programming could be saved without having to tinker in the source code.

[t0mpr1c3]

What needs to go into the API -- what does the desktop need to know?

As an API issue, this probably needs to go into v1.0.