Design firmware that receives text commands over UART, like "SET LED 1", and responds reliably.

What the interviewer wants to hear

• ISR or DMA pushes bytes into a ring buffer
• A task or main loop assembles lines and parses them
• Bounded line length and input validation
• Command table mapping names to handler functions
• Error responses, timeouts and overflow handling

Model answer

I keep the interrupt side minimal: the UART receive ISR, or DMA with idle-line detection, pushes bytes into a ring buffer and maybe signals a task. A parser task or the main loop pulls bytes and builds a line in a fixed-size buffer until it sees a newline. If the line gets too long I discard it and report an error, so a bad sender cannot overflow memory. I then split the line into tokens and look up the first token in a constant table of command names and handler functions, which keeps parsing clean and easy to extend. Each handler validates its arguments, like range-checking the LED number, and returns OK or a clear error code. I also handle ring buffer overflow by counting dropped bytes, add a timeout for partial lines, and write host unit tests for the parser with good and malformed input.

More medium Embedded Systems Engineer questions

• How would you write a driver for a new I2C temperature sensor?
• Explain the difference between a mutex and a semaphore in an RTOS, with examples.
• A device freezes randomly once every few days in the field. How do you debug it?
• Explain the memory layout of a typical microcontroller program: .text, .data, .bss, stack and heap.
• When would you use fixed-point arithmetic instead of floating point on a microcontroller?
• What is DMA, when would you use it, and what pitfalls do you watch for?
• Explain how the CAN bus works and why it is popular in automotive and industrial systems.
• Your firmware is close to the flash and RAM limits of the MCU. How do you reduce memory usage?
• How would you design a watchdog strategy for firmware running several RTOS tasks?