A while back I got some help for serial communication between my c# desktop app and an Arduino Uno. Everything got sorted out and my issues got resolved and I have a stable solution in place. Now we're a few months later and I'm trying to do the same thing on a bigger scale and could use some advice.
One comment made by Robin2 about the chunk size has made me rethink my approach.
Robin2:
If you want to send a lot of data in fixed length chunks I suggest you get the Arduino to "request" the chunks - perhaps by sending an 'M' (for more ). That way synchonization is ensured.
Sending small chunks of data will not permit a large overall throughput. You could probably send chunks of 36 bytes as quickly as chunks of 6 bytes.
...R
I can group the data I'm sending in different ways.
On my first try I'm sending 12 packets 68 bytes where I ran into a problem of the Serial RX buffer.
I'm solving this problem by changing the buffer size in the HardwareSerial.cpp file.
Now some questions.
Starting with the obvious. The comment made by Robin2 is correct right? Bigger chunks can be as fast.
Should I limit the size of the packets to fit into the default buffer size of 64 or can I go bigger?
If I go bigger, what is there a maximum size I shouldn't cross?
And also, is there a better way to increase the buffer size without changing the source file?
One of the lines is the following;
if !(defined(SERIAL_TX_BUFFER_SIZE)&& defined(SERIAL_RX_BUFFER_SIZE))
Here I would assume that if i can define it somewhere else the source file should just use it.
But where would I do this and how?
(If it's even an issue.. If I shouldn't exeed the buffer size its no point)
On my first try I'm sending 12 packets 68 bytes where I ran into a problem of the Serial RX buffer.
I'm solving this problem by changing the buffer size in the HardwareSerial.cpp file.
Why is the necessary? The PC can read data faster than the Arduino can send it.
Should I limit the size of the packets to fit into the default buffer size of 64 or can I go bigger?
Absolutely. Or not. On the Arduino, when the outgoing buffer gets full, the Serial.write(), .print(), and .println() methods block, waiting for there to be room in the buffer. That may, or may not, be an issue. We don't know, since you posted no code and have done nothing but wave your arms around.
The baud rate and method of getting the serial data sent (wired, wireless) has an impact, too. Whether there is handshaking (not hand waving, we know that's happening) or not is a factor.
If I go bigger, what is there a maximum size I shouldn't cross?
Of course. 1024 bytes for each buffer will use all of the SRAM that you have.
And also, is there a better way to increase the buffer size without changing the source file?
There is ONLY one way to change the size of the buffer... The size is defined in the software.
Here I would assume that if i can define it somewhere else
hardcorehead87:
.
Should I limit the size of the packets to fit into the default buffer size of 64 or can I go bigger?
If I go bigger, what is there a maximum size I shouldn't cross?
And also, is there a better way to increase the buffer size without changing the source file?
One of the lines is the following;
if !(defined(SERIAL_TX_BUFFER_SIZE)&& defined(SERIAL_RX_BUFFER_SIZE))
Here I would assume that if i can define it somewhere else the source file should just use it.
But where would I do this and how?
(If it's even an issue.. If I shouldn't exeed the buffer size its no point)
There is a lot to be said for NOT changing the Serial buffer size because changing it will mean you need to ensure always to use the special version of the code. I did consider enlarging the buffer for a project I have but eventually I decided it was not worth the trouble.
I guess I could see some advantage going up to (say) 68 bytes if that happens to coincide with some package of data you need to send. However if the data comes naturally in 34 byte chunks I would just work with that rather than sending 2 at a time. At the other end of the scale if the natural size is 68 bytes I would not bother to increase the buffer to twice that size because it starts eating up your precious SRAM. And, unfortunately, HardwareSerial uses the same size for its input and output buffers.
To pick up on a comment by @PaulS, if your Arduino code can read the data more quickly than it can be received there is no reason to limit the data size. But in the project I am working on it is very useful to let the PC send a chunk of data while the Arduino is busy processing the previous chunk - and in that case the chunk must all fit in the buffer.
Another factor to bear in mind is that 64 bytes is a standard USB packet.
My goal is to know what I can and can't (should/shouldn't) do when it comes to the serial buffers.
The data I send from the PC to the Arduino exceeds this buffer and there are 2 options.
Either I reduce the data size or I increase the buffer size. I thought that much was clear from my question.
I can provide some example code but @Robin2 pretty much sums it all up.
The code in my HardwareSerial.cpp is similar to what is here;
There is a check to see if the variables aren't defined, they get defined.
If they're already defined somewhere else these predefined values would get used.
There is no way to predefine these values as my assumption is invalid.
So there is no way to set it like a global variable and have that be used.
In that case it would indeed be a hassle to have the serial implementation deviate from the default.
Also if I would distribute the code it would require the change with other people.
All this adds up in favor of NOT changing the serial buffer size ;-)..
The data comes naturally in 8 byte chunks. So these questions would answer how I group these chunks. It's very flexible on that point so I can get arrange it in less/more than 64 byte if I want.
Every packet has some checksum stuff so getting the most data in a single package is better.
Thank you for the help
Conclusion is that I'll reduce the data size and keep the HardwareSerial implementation stock.
Conclusion is that I'll reduce the data size and keep the HardwareSerial implementation stock.
I think that's the best decision, given that you want to distribute the application.
One thing to consider is that the Arduino can read data far faster than it can be sent. Making sure that the Arduino checks for data often enough should be everyone's goal.
). That way synchonization is ensured.
