A firmware-independent method of assigning Node IDs to cards is needed to ensure that a firmware image for a particular type of card can be generic. As it stands, Node IDs are hard coded into the firmware images, which means we need to rebuild and keep multiple firmware images around to program cards with the correct Node ID. If Node IDs were held in some configuration space that the firmware could read from, we could set-and-forget the Node ID of a particular card and just load a generic firmware image into place that pulls the Node ID from this location.
The challenge here is that there's not really consistent way to do this on our cards just yet. There's a "user data" option byte on STM32F091 cards, but not on the STM32F446 (but the F446 does have a OTP section). This means either the OreSat application code conditionally compiles code for an image based on whether it's on one card or another, or we find a different means of consistently setting Node IDs on cards.
A firmware-independent method of assigning Node IDs to cards is needed to ensure that a firmware image for a particular type of card can be generic. As it stands, Node IDs are hard coded into the firmware images, which means we need to rebuild and keep multiple firmware images around to program cards with the correct Node ID. If Node IDs were held in some configuration space that the firmware could read from, we could set-and-forget the Node ID of a particular card and just load a generic firmware image into place that pulls the Node ID from this location.
The challenge here is that there's not really consistent way to do this on our cards just yet. There's a "user data" option byte on STM32F091 cards, but not on the STM32F446 (but the F446 does have a OTP section). This means either the OreSat application code conditionally compiles code for an image based on whether it's on one card or another, or we find a different means of consistently setting Node IDs on cards.