min-protocol / min

The MIN protocol specification and reference implementation
253 stars 87 forks source link

Testing MIN with serial monitor #41

Closed subodh-malgonde closed 1 year ago

subodh-malgonde commented 1 year ago

I am working with STM32 discovery board and I am testing this framework with a serial monitor (Docklight) since I don't have the host code setup yet. Since I know the frame structure I can construct a valid frame and send it via the serial monitor to the MCU.

Sending data from serial monitor to MCU works fine. When I send data from MCU to the serial monitor, I notice these things:

  1. When sending via min_queue_frame, I receive the frame in the serial monitor multiple times. I am guessing that since there is no host code sending ACKs to the MCU, the target code keeps resending the frame. Am I correct?
  2. When sending via min_send_frame I notice that one another frame is sent repeatedly to the serial monitor - AA AA AA FF 00 01 00 E6 5A E8 AC 55. This frame is sent 9 times after the original frame. What is this frame?

On a more general level, since these things are not mentioned in the wiki:

  1. What is the main difference between the transport protocol and sending via min_send_frame? I read that the transport protocol guarantees delivery, but how is that achieved? Is it via sending ACKs from host to MCU?
  2. How can I construct the ACK frame? I want to send the ACK when testing with a serial monitor.
  3. If I use min_send_frame will frames be dropped on a noisy line?
kentindell commented 1 year ago

If you are using the transport layer on top of the basic MIN layer then there will be automatic timeout and re-send, yes. So for the transport layer, a host needs to be connected to ACK the MCU's frames.

The transport layer runs on top of the basic framing, and is designed for MCUs with more RAM for buffering. It's a very simple protocol, with a sliding window and ACKs to move the window. But it's a connected system: there is another end to it. There's no API to construct the ACK frame: it's part of the protocol at each end. If you want to test it, I suggest getting the Python code running and then adding debug output directly from the serial driver that you can put into your monitor to see what's happening on the way.

The basic framing layer will drop frames on a noisy line: it's like Ethernet or LIN in this respect and not like CAN. This is why the transport layer was created (many applications do not need this, of course, since an application using repeated sensor data means that another value will arrive soon anyway).

subodh-malgonde commented 1 year ago

Thank you. That answers all my questions. Thank you again for making this library which is very useful and simple to use & understand.