loading
 
Reliable MCU communication
Sergey from Russia  [5 posts]
7 year
Hello! I am glad to join the community.

I'm looking for a way to reliably pass variables from RoboRealm to the MCU and back. At first, I tried to organize communication with the Serial module. But the transmission was unreliable, the variables can be swap sometimes, and sometimes they were not delivered. It seemed to me it depends on in what sequence MCU and RR runs. Also I have not found an example of a full implementation of the communication protocol.

Next, I drew attention to the MCU communicator module. But then something went wrong. At a speed of 115 200 kbit/s does not happen anything. At the 9600 kbit/s variables change very infrequently, an incoming text string distorted. If I disable text mailboxes situation is somewhat better but not perfect. The same thing happens on Arduino Uno and the latest version of the IDE. Just *.pde extension gave me the idea to try the old version of the IDE.

My goal is to port the code to the STM32 MCU. Is there a way to reliable transmission of the variables to the MCU and back? Do I understand correctly that if the checksum is incorrect in MCU communicator, the variable is just skipped, do not resent again?
Steven Gentner from United States  [273 posts] 7 year
Sergey,

Are you working with a wireless connection?

The MCU module would be the best to use but it isn't built to be 100% reliable communication since most communication to an MCU is done over serial and one only gets the occasional error that should just be ignored as apposed to acted on. So, yes, when a crc is invalid it will just be skipped and no re-transmission is requested (this isn't an implementation of TCP!).

What is most likely going on is that the Arduino or other MCU just cannot keep up with processing the incoming data quick enough which is why at 115 nothing happens since the crc is probably failing every transmission. See if you can find a compromise between the slow 9600 and fast 115.

Be sure to also just send numbers and not text. If you have many small numbers to send we can add a small int or byte number (0-255) which would save a couple bytes on transmission.

We've found that shorter/smaller protocol even at 115K is always recommended. Try to compact as much of the information into as few bytes as possible. That will definately allow the MCU to keep up with the transmission rate and create more reliable numbers.

STeven.
billy from United States  [10 posts] 7 year
Sergey,
At 115 using the serial module, I've have had serious issues also with some of the data never being transmitted, or bits data coming back from the uC not being received. I have a logic analyzer so there isn't any question about where the issue is. For me it's definitely in the PC (not uC). But after lots of playing around with the settings of the serial module, it can be made to work. For me this issue is new so I assumed it is related to Windows version or hardware. I didn't have this issue on older PCs running older versions of windows.  Now using Surface Pro 3 with Windows 8.1.  

Take additional time with the settings before deciding it won't work. If you have anyway to sniff the line, even better.
Sergey from Russia  [5 posts] 7 year
To STeven: No, I use a wired connection to the Arduino. Sorry, I forgot to give the link in the initial report: https://youtu.be/Aif3xxDimWM I'll try to port the device on the STM32. What do you think, whether will be more reliable to use a Socket Server via ethernet TCP? Could you explain in more detail how to use the Receive Sequence? Sometimes I need to pass a single variable, sometimes 10. Can I create there several matches? Do I need to start them in a new line?

To billy: I've noticed that sometimes it works as it should, more often not.
Steven Gentner from United States  [273 posts] 7 year
Sergey,

The serial receive sequence is just meant to match a simple serial protocol. If you have more complex data I would recommend using something like

[data]\r\n

which would pick up any serial data and stick it into a variable called data which can then be further processed using one of the scripting modules (GetStringVariable function). This allows for more complex parsing that might change depending on the data sent. Note the CRLF used to delineate a line. You can use whatever you want, just be consistent with what you send and what you expect to receive.

For example, sending

1:2:3:4:5\r\n

would put "1:2:3:4:5" into the "data" variable which can then use a split on ':' in a scripting module to get the individual elements.

STeven.

This forum thread has been closed due to inactivity (more than 4 months) or number of replies (more than 50 messages). Please start a New Post and enter a new forum thread with the appropriate title.

 New Post   Forum Index