Include board ID on rev5 mobo
konkers opened this issue · 6 comments
Version Number
mobo rev5
Bugfix or Enhancement
Enhancement
Description
Provide a mechanism for reading the hardware board id/revision on the mobo. The will allow the for a single firmware image to support multiple board revisions and reduce/eliminate the likelihood that a customer will flash the wrong firmware when updating.
Suggested Solution
Either include a set of strapping resistors (4 bits is usually enough) on GPIOs or a resistor divider on an analog input.
Unless I've misunderstood, Marlin doesn't support dynamic board detection like this. There are features on the board including the git hash to identify a specific build.
If opulo wanted to support this without hardware changes in the future, they could also look into if there is EEPROM space available on the STM32 which could be burnt with board revision details.
Yeah, the STM32 doesn't really have EEPROM. It has flash blocks only. However, it does have a small OTP are which can be useful for writing in serial numbers and the hardware revision or other things like that. I've done this in the past on other projects. The only downside is that you can't transplant the STM32. So I'd say it's useful for board revision/SN but not machine data, since that might change.
Unless I've misunderstood, Marlin doesn't support dynamic board detection like this.
That's both surprising and unfortunate :(
If opulo wanted to support this without hardware changes in the future, they could also look into if there is EEPROM space available on the STM32 which could be burnt with board revision details.
In my experience putting board revision in flash or eeprom is marginally better than maintaining multiple builds for each revision. There are always cases of someone forgetting to program the revision, programming it wrong, or erasing it.
From a quick look at the schematic, there look to be plenty of unused IO on the microcontroller. At the cost of a few 0 ohms, you can have a board ID that doesn't require any programming, is fully encapsulated by the BOM, and easy to change if reworking a board to a new board revision.
The only downside is that you can't transplant the STM32. So I'd say it's useful for board revision/SN but not machine data, since that might change.
You also have to replace the microcontroller if you are going to rework a board up to a new revision.
Thanks for the idea @konkers!
Yeah the Marlin integration is the real hesitation for me here. In a world where we have a smart flashing utility that decides which firmware a board should receive, there are some cheeky things we can do that could check hardware (regex on output of M115 existing firmware image machine name to identify, checking which vacuum sensor type responds), but they're not really good solutions, and they're changed by firmware updates.
That being said, Marlin does support reading a pin state with something like M43 P12 I, so we could pull this information out via the existing Marlin API. It would mean synthesizing a hardware version number from the result of a few Gcode commands, but if adding this feature to Marlin isn't straightforward, I think this is a pretty good secondary option.
Curious what y'all think of this.
If you're going to do this in hardware, use pads with cuttable traces rather than 0 ohms.
If it were me, I would program the revision information in OTP or similar.
I don't think this is super important and Marlin is clearly not set up for this.
Given that there's no support in Marlin, I agree that the value is pretty low.
A downside to using cuttable traces over 0 Ohms is that one would have to either do a board spin or manual rework for changes that are pin compatible but not software compatible. Swapping out things like sensors or adcs or changing gains on op amps come to mind.