I doubt anyone using an 8-bit MCU would start using 16-bit anything as part of a protocol. That's why they make 16-bitters!

Further, I doubt anyone would go so far as to use a keypad entry system for 200 commands. I'd guess it would take the form of a fairly simple command and a parameter or two, in which case the code would be tested separately, command recognition first, then parameter assessment.

Use the UART? Probably not, and if it had to be used, it could be done at test speed and not necessarily at 300 baud.

When it's hard to reach certain modules, one can verify their proper function and program flow separately.

For one who so often advocates for the use of large-core MCU's, I'm surprised that you'd suggest one use an 8-bitter as you've suggested.

I'm not sure your suggestion of using a state-machine to interpret keypad-entered commands and data is wise. I think table-lookup makes it sounder, quicker, and much more testable. That's just my opinion, of course. That's why my 8KB of code space is often <1kB of code and >6kB of table space.

With a table-lookup, all the valid entries are vectored through the table to their appropriate routine, while the invalid ones are vectored to an error handler. It's really simple. I think you've overcomplicated the problem. Maybe that's why you frequently find 32-bit MCU's more useful than 8-bitters.

After all, I've been doing this sort of thing since there were commercially available microcontrollers, and never gotten into a position wherein external hardware couldn't detect and monitor what was going on. With some MCU's, it was even possible to monitor the internal state of the MCU from outside with proper logic analyzer timing, so one could observe what was going on inside the subject MCU. This wasn't possible with ALL MCU's but certainly with some families. Maybe it's just a matter of style.

RE