mjstn
commented
3 years ago Where the bit resides is a topic of study. That I will reply to later.
Where the logic resides seems higher level than serial. serial is a packet driver that should not know or try to think about internal mcb state is my thought. If the busy bit has anything to do with the content of the message, which I can see cases for, then an automatic setting of this state in a packet driver seems not a good place to manage the bit. Notice that the busy bit is only sometimes set (for queries) so we do not overrun MCB on queries. I have not yet determined if there are some cases for writes where we want to also set busy bit. Also the idea is the mcb itself can set busy bit which is a firmware decision that adds flexibility for firmware to try to hold off host layer messages. So having a layer that is the only interface on top of the mcb that can understand what messages require what busy bit interactions is why it is in motor_hardware.cc
a new motor_message.h bit called MCB_BUSY_STATE_MASK is allowed to be controlled by firmware. Host will set a busy state in motor_hardware.cc when sending queries to MCB. MCB must return any message with this bit cleared (was upper bit of mcb register which we never have used anyway).
The intent of this change is to be backward compatible with existing firmware and allow future firmware such as v38 to extend any MCB busy time within reason as required.
The change as it exists now will give up and send messages if it takes over 200ms so we do not break things badly. That is a little 'dirty' but frankly for this sort of architectural change so late in the stages of assorted firmware this is cautious.