Go Down

Topic: Does one Need to Slow Down Processing in Order for Arduino to Catch Up? (Read 1 time) previous topic - next topic

PaulS

You could have Processing send the int as 2 bytes, and have the Arduino read the two bytes and reassemble the int. No need to convert to ASCII and back.

DROBNJAK

Problem is that I need to manage a complex device, with minimum 2 servo motors and few sensors. So I can't just send 2 bytes. I need to send one byte as identifier for 2 other bytes. In other words, they must go in command-parameter formation. Now, as far as I currently see, bytes in formation: "sXX" must have terminating byte, so it is maybe more like "sXX\n" which is already 4 bytes. It seems that lengthy commands like "servox 2179\n" are drag.

I really didn't expect that bottleneck is going to be on Processing side, since it runs on PC with all that hardware power attached. I tried some other Processing code, that is sending only a single byte and that runs perfectly smooth, even at 9,600 baud.

PaulS

Quote
Problem is that I need to manage a complex device, with minimum 2 servo motors and few sensors. So I can't just send 2 bytes. I need to send one byte as identifier for 2 other bytes.

So do that. What I meant was that if you need to send a value, like 589, to the Arduino, you can send that as two bytes or as a string ('5', '8', '9'). Performing two reads, a left shift, an add and a store is going to be a lot faster than reading 3 bytes, and converting the 3 characters to a number.

Of course you still need to send an ID, and probably start and end markers.

Sending data when the Processing application and the Arduino are both ready should not require a delay() on either side. I don't know where the Processing or Arduino code in the SerialCallResponse example uses delay(), but they should not be necessary.

The code I have for Processing and Arduino exchanging data has no delay()s.

Go Up