The speaker _does_ do a great job of echoing or re-phrasing the audience questions. That's an excellent technique for the rest of the audience to hear the question, and for a speaker to give themselves time to think, and for a speaker to get themselves in the questioner's point of view to give a better-phrased answer.
23:00-ish : what proportion of the code footprint is in the state machine, if you'd begrudge twice the footprint for better control and maintainability? Or - likely - am I missing how tight the memory constraints are?
You probably aren't missing anything at all. While memory constraints can be very tight in some systems we are more often just reluctant to give up any performance or memory for a nice abstraction. When state machines are used in higher levels of a program the proportion of the machine compared to the getting-work-done-code is negligible. However, when the state machine is being utilized as a protocol machine or something very low level, the state transitions and state accounting is the majority of the task. Think about maybe using a state machine as a parser. C++ programmers are notoriously stingy about giving up performance. With the right techniques, we can have great abstractions without paying any performance penalty.
Organizers must enforce mics in auidence. Half of the video is conversation with auidence and it is impossible to listen questions and answers
The speaker _does_ do a great job of echoing or re-phrasing the audience questions. That's an excellent technique for the rest of the audience to hear the question, and for a speaker to give themselves time to think, and for a speaker to get themselves in the questioner's point of view to give a better-phrased answer.
@@williamchamberlain2263 Not towards the end. It's like listening so someone on he phone at the next table in a restaurant.
Did someone really leave a comment saying Michael knows nothing about firmware? That's nonsense.
23:00-ish : what proportion of the code footprint is in the state machine, if you'd begrudge twice the footprint for better control and maintainability? Or - likely - am I missing how tight the memory constraints are?
You probably aren't missing anything at all. While memory constraints can be very tight in some systems we are more often just reluctant to give up any performance or memory for a nice abstraction. When state machines are used in higher levels of a program the proportion of the machine compared to the getting-work-done-code is negligible. However, when the state machine is being utilized as a protocol machine or something very low level, the state transitions and state accounting is the majority of the task. Think about maybe using a state machine as a parser.
C++ programmers are notoriously stingy about giving up performance. With the right techniques, we can have great abstractions without paying any performance penalty.