UNO Q communication: what should the MCU do when the Linux application stops?

Include freshness information in the protocol: a sequence number and a defined timeout or heartbeat policy. Let the MCU evaluate freshness using its own monotonic timebase rather than trusting unsynchronized clocks. The correct fallback may be stopping or another bounded state, depending on the mechanics and requirements.

Keep the local control loop independent of application messages. Messages should update a validated setpoint; they should not directly determine when each control iteration runs. Reject out-of-range values and malformed messages, and define behavior at startup before the first valid command arrives.

Test application termination, delayed messages, disconnection and both processors restarting in different orders. Do not automatically resume motion merely because communication returns if the application requires an explicit restart. Record the maximum command age observed under normal load so the timeout reflects measured behavior rather than a guess.