[enh. doc.] How does the main loop protocol work? How to check for timeouts?

[PizzaProgram]

Please enhance the Protocol documentation, by adding important infos, about:

• How the different "frequencies" work?

  • in main loop in .ino file
    is it safe to slow down by inserting delay(1); ?
  • if message received
    (how does it know when it finished, how to decide, if it was disconnected -> and just waiting endlessly)
  • same for message sent to the host

• How to implement timeouts on host side the best way?

• Does the main loop sends any ("ping") message periodically?

[PizzaProgram]

Why are these infos important?

Because currently Firmata is (sadly) not 100% stable for industrial use.
With a little more effort, it could be, if there would be more infos about it, to:

• enhance the code to work more safely.
  (timeout, parity bit (crc), identification, password protection, ...)

[pgrawehr]

Now that you mention it, I've seen similar issues, but it does considerably depend on the actual hardware (an ESP32 is very different from an arduino uno) and the task at hand.

Communication can become unstable if the internal buffer of the firmata device overflows. Normally, it will just drop the commands and print a warning to the console, so you should at least see when that happens. So you shouldn't be sending data faster than what the mcu can handle, due to the missing handshake, this is in particular true for communication with external devices with large block sizes (eg. an SPI display).

As you have found in #180, the RPI Pico mostly ignores the baud rate, so you can definitely flood the mcu. To fix this, you can either:

• Introduce a delay after each message transmitted on the host side
• Where possible (e.g. I2C or SPI communication) ensure you're sending data only after the reply to the previous request was received. Many commands where upgraded in V3.X for exactly this purpose.
• Use a TCP connection (e.g. Wifi) instead of serial, as that has built-in flow-control (and also guarantees data integrity).

V3.0 should always allow a reconnection, as the software reset command is always available, regardless of the state of the parser. Previous Versions may not always work.