Can the Serial input buffer (Specifically Serial1 on the Mega 256) be made larger. I am having a buffer overflow problem when this is used for Bluetooth input. A bigger buffer would solve my problems.
wm
Yes, you can.
Or you could correct your own code, and maintain compatibility.
Have a look at the examples in Serial Input Basics - simple reliable ways to receive data. They take data from the serial input buffer and store it in an array of a size that you control.
...R
Thanks for the replies (not the snarkiness). I do intend to fix the code, but first I need to see why it is overflowing. Some context, when running at 9600 baud from the USB there is no problem. It is only when reading from serial1 connected to Bluetooth also at 9600 baud do I get the overflow. I would like to expand the buffer temporarily so I can examine exactly what data is coming across and if it differs from the data coming via usb. I can't do that without good data. So if it is possible, where do I find the code for serial since it is not a library. BTW I an not a newbie when it comes to programming or arduinos. It is just that the "sending" program is not mine and I don't have access to its code so I have to debug from the arduino's end.
And then? Then you see you have a lot of data... What are you going to do about it?
9600 baud isn't that fast. Do you keep you're Arduino waiting somewhere? Possible a delay()? Or one of the terrible serial parse functions like Serial.parseInt() of Serial.readBytes() or something?
wmassano:
It is only when reading from serial1 connected to Bluetooth also at 9600 baud do I get the overflow.
Then there is something else wrong with your program.
I regularly use the code in Serial Input Basics at 500,000 baud on an 8MHz Atmega 328.
...R
Hey I think I have a problem like this too, I have a program that sends angle and the distance, a ',' between them and a '.' at the end so I can split those 2 in Processing. I made a radar through bluetooth, and I have a servo motor with a delay(30);, but when it's connected to bluetooth the servo isn't running smoothly, it runs and stops the whole time. Is this because of the bluetooth, and the serial buffer thing?
akatchi:
Hey I think I have a problem like this too, I have a program that sends angle and the distance, a ',' between them and a '.' at the end so I can split those 2 in Processing. I made a radar through bluetooth, and I have a servo motor with a delay(30);, but when it's connected to bluetooth the servo isn't running smoothly, it runs and stops the whole time. Is this because of the bluetooth, and the serial buffer thing?
How the Hell can we tell?
Please don't hijack threads
Hard to tell because you hijack a thread and don't post code...
But probably not. If the serial buffer gets full you have two options
- send less data (which is not the same as a lower baud)
- read faster!! <- This is the real solution
And a delay() in a program is always a bad idea... Try replacing it by a non-blocking wait. See Blink without delay.
And then? Then you see you have a lot of data... What are you going to do about it?
It won't be a lot of data, maybe a few hundred bytes. By seeing what comes through with the expanded buffer and comparing it to the one that chokes, I can tell if it is on the arduino end or the "black box" end. If on the arduino end, I will try various techniques to further optimize the code, but I don't want to waste my time if it is on the other side. Then, about the only thing I could try would be to lower the baud rate, or make a custom copy of Serial with the expanded buffer. I have had this occur with other systems and the technique has worked before. Knowing the data is coming through intact and is not corrupted in some way is the first step in tracing the problem rather than "fixing the code" and hoping that was the problem. Again, thanks for all the suggestions for a fix, but first I want to be sure of the problem.
wmassano:
It won't be a lot of data, maybe a few hundred bytes. By seeing what comes through with the expanded buffer and comparing it to the one that chokes, I can tell if it is on the arduino end or the "black box" end. If on the arduino end, I will try various techniques to further optimize the code, but I don't want to waste my time if it is on the other side.
If all you want to do is gather the data on the Arduino so you can look at it then that's what the link in Reply #5 does - without wasting any time.
And it will probably be a good base for a longer term solution also.
...R
If you want to know what's really coming though / to see it's not corrupted, simply DON'T put it trough the Arduino. Simply connect it to the Serial-USB cerverter and read it.
Because if you need a bigger buffer because it's full you simply don't read it fast enough...
wmassano:
Then, about the only thing I could try would be to lower the baud rate
septillion:
send less data (which is not the same as a lower baud)
Yes, at a lower baud rate you get less data per unit of time and then the Arduino might be able to handle it. But that's not really fixing the problem (which is you not reading the serial buffer often enough) but merely a workaround.
I had similar problems with serial data arriving too quickly and overflowing the buffer.
You need to analyse when the data arrives, not what the data is.
I found that each new burst of data was arriving 250ms after the previous one, so I just had to make sure I didn't start any complex/time consuming processes just before I knew I needed to be monitoring the serial port. In my case the data was arriving at a high baud rate and would fill the serial buffer (and cause an overflow) within a few milliseconds - hence the need to know when the data was due before it actually arrived
You need to analyse when the data arrives, not what the data is.
That is EXACTLY what I was trying to do by expanding the input buffer temporarily, which NO ONE here would tell me. I finally found it elsewhere. Before I state the results, I would like to know what happened to this forum?? It used to be that you could ask a question and get knowledgeable replies. While some tried to offer help, no one answered the question and others just gave pronouncements from on high "FIX THE CODE". This isn't help and if I were a newbie (instead of 40 years of experience) I would be lost. BE helpful or be quiet! I was trying to save some time by asking people who should know. My mistake
Now for the answer. Before I found the Serial buffer, I just wrote a program to dump the data and reduced the speed to 300 baud. When it ran on the USB I got what I expected. When on Bluetooth there would be random bunches of garbage along with the data and the buffer was still overflowing. This led me to the Bluetooth module. I replaced it and the problem was solved.
To all the "FIX THE CODE" experts, there was nothing wrong with the code, it was defective hardware!!! Next time someone asks a question, especially one that shows he know what he is doing (or even if he doesn't), give him the info or give him guidance. Leave the attitude at the door.
You have 40 years of experience, you're so emphatically not a noob, and you couldn't find the source to change the buffer size?
No. Just, no.
Please, you're fooling no-one.
wmassano:
To all the "FIX THE CODE" experts, there was nothing wrong with the code, it was defective hardware!!! Next time someone asks a question, especially one that shows he know what he is doing (or even if he doesn't), give him the info or give him guidance. Leave the attitude at the door.
Glad we could help you out.. even tho I'm a noob I'll keep trying to help other people out who had the same issues like me in the beginning, of course we can't smell the problem, it's always hard to figure out a problem man.
You could also thank the people who gave their input and tried to help you out, AWOL, PaulS, /dev, Nick, these people help almost all the people on these forums, just because they want to help people, it's not their job or something.
wmassano:
Now for the answer. Before I found the Serial buffer, I just wrote a program to dump the data and reduced the speed to 300 baud. When it ran on the USB I got what I expected. When on Bluetooth there would be random bunches of garbage along with the data and the buffer was still overflowing. This led me to the Bluetooth module. I replaced it and the problem was solved.
Messing about with software is not how I would troubleshoot a problem like this, how can you prove the software changes are valid ?
A seperare serial adaptor monitoring whats happening on the serial port would have shown the problem you described with no software changes required.
wmassano:
I just wrote a program to dump the data
That's what is in the link I posted in Reply #2
...R
Please, you're fooling no-one
As moderator I think you would read ALL the words in a post before making an obviously wrong comment. I found the serial buffer source code. I was just hoping to save some time rather than rooting through a half dozen folders to find the source. Some of us have a life outside of programming. As to your disbelief of my experience, I am really distraught -- NOT! Your wrong (again ) opinion means nothing. Again, just help the people! I don't care who's is bigger. I have fixed my problem and now that the last bug in my hexapod's program is gone, I can demonstrate it to my computer engineering students.
It may have gotten lost in the silliness that has gone on, but I did appreciate those who tried to help, I just was annoyed at those who made pronouncements without helping. To all those who offered their help I THANK YOU ALL.