Hi all,
i had this question a few weeks back , after the change in flush() method it had become quite difficult to empty the serial buffer , so to all those who require to send large amounts of data from processing or serial monitor to arduino, just use this code. Only prerequisite is that the data must be sent as a bulk, no delays are required.
void loop()
{
if (Serial.available())
{
val="";
while(Serial.available())
{
char t= Serial.read();
val=val+t;
}
Serial.println(val);
Serial.end(); // Ends the serial communication once all data is received
Serial.begin(9600); // Re-establishes serial communication , this causes deletion of anything previously stored in the buffer //or cache
}
}
later u can just use the substring method to extract from val
I'm still of the opinion that any attempt to 'flush' the serial input buffer is flawed thinking as one has no control over what and when new serial data my arrive, possibly even between the ending of the flushing function but before returning to further processing that assumes the input buffer is empty when it's possible it is not, esp at the higher baud rates.
I think this kind of requirement is better met by 'building' it into the serial protocol so that one can simply throw away all characters until a valid start of packet character is read and then save characters until you get a valid end of packet character. So build the structure into the protocol rather then assuming what may or may not arrive or assuming what data you don't need even though you haven't determine what those flushed characters might represent.
Recall that the older arduino flushing function did clear the serial input buffer, but they changed it around IDE => 1.0 to flush only the output transmit buffer and left no function to clear the input buffer. If it was a useful or logical function why would they remove that functionality? I certainly am open to what others may have to say on this subject.
Strange. My serial code generally has output waiting, it no-blocks serial input and never reads more than 1 char per loop() it's generally a lot of loops() between serial available even at 115200 baud.
Isn't flush() supposed to flush the transmit buffer? That's the one you can load 1000's of times faster than it can send.
The only serial input you should have trouble keeping up with is SPI.
But if you do have problems keeping up with serial, you might want to find out what's blocking in your code.
I recently had a similar problem to send data to Arduino Unity and I developed this little demonstration.
It has the advantage of adjusting the write speed of Arduino speed at which empties buffe ...
Please note that is just a small demonstration.
int MaxBytesAvailable;
int CurrentAvailable;
int delayNumber=1000;
int n;
String messageOut;
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
MaxBytesAvailable=Serial.availableForWrite();
}
void loop() {
// put your main code here, to run repeatedly:
messageOut="";
messageOut+=Serial.availableForWrite();
messageOut+=" Current Delay =";
messageOut+=delayNumber;
Serial.println(messageOut);
for(n=0;n<delayNumber;n++)
{
if((CurrentAvailable=Serial.availableForWrite())>=MaxBytesAvailable) break;
}
if (CurrentAvailable>(MaxBytesAvailable/2))
{
delayNumber-=100;
if(delayNumber<0)delayNumber=0;
}
else
{
delayNumber+=100;
if(delayNumber>65000) delayNumber=65000;
}
}
What about just adding a simple while loop whenever you want to clear the buffer?
while(Serial.available()){Serial.read();}
In my design, there shouldn't be any data in the buffer, but I include this just in case there was some old data that didn't get read for some reason.
all that is so complicated and abit long winded, why cant it just be serial.clear, or if (serial.read = "clear" ) {
} serial.clear}
or something along them lines! omfg!
multimedia:
all that is so complicated and abit long winded, why cant it just be serial.clear, or if (serial.read = "clear" ) {
} serial.clear}
or something along them lines! omfg!
Because throwing away serial data without any regard for what is there is generally considered "stupid as f&%k" and the people who wrote the language weren't generally that stupid. If you're throwing away random amounts of data you should at least be looking for valid packet start markers while you do it. But really, if you find yourself just blasting through throwing much away then you probably have a seriously flawed program or protocol and you should really fix that first.
multimedia:
To output to an lcd :)and then to enter more data you overload buffer therefore i need the serial buffer cleared b4 putting a new string in.
That doesn't make any sense without context. Writing to the LCD and receiving serial have nothing to do with one another.
Its a project im working on dw about it. how can i clear it with a small command not a 10 mile long bit of bloated code, who can help without asking 20 questions as im in a poker tour right now!
multimedia:
Its a project im working on dw about it. how can i clear it with a small command not a 10 mile long bit of bloated code, who can help without asking 20 questions as im in a poker tour right now!
A while loop. Write the function you want. Fix your design so you don't have to. There's three options that don't require 10 miles of code.
Im a noob at c so all I see is long code and that's all i have to work with, please give me a really basic example, the serial buffer normally gets outputted to the lcd screen, but the lcd is 16, 1 and fills up and stops any more input and even puts in strange chars if i try to add more in so maybe i need to use the lcd.clear but then it might just fill with the serial buffer again and it wont achieve any clearing, so i think clearing the serial buffer aswell as lcd.clear will work a lot better but have no idea what the code to do that is.
Not me, I'm pretty damned good at this if I must say so.
multimedia:
please give me a really basic example,
After you called me a cunt earlier? I see you took it down, but I saw it. Maybe a sorry would help.
multimedia:
the serial buffer normally gets outputted to the lcd screen,
No, not normally. Normally the two have nothing to do with one another. Nothing gets sent to the lcd unless you send it there in your code. That's why I asked for context. Are you talking about a serial lcd? Are you talking about the send buffer or receive buffer?
multimedia:
but the lcd is 16, 1 and fills up and stops any more input and even puts in strange chars if i try to add more in
So don't send so much to the lcd. You have control over what you send from your code.
multimedia:
so maybe i need to use the lcd.clear but then it might just fill with the serial buffer again and it wont achieve any clearing, so i think clearing the serial buffer aswell as lcd.clear will work a lot better but have no idea what the code to do that is.
I have no idea what that code is either because I know practically zero about your project or which components you have or the code you are using. If you want help, then you'll have to be forthcoming about those details.
There are many kinds of LCD. Which one do you have? How does the board communicate with it? Serial? I2C? SPI? Parallel?
I'm still not clear on the connection between the serial buffer and the LCD in your program. That's something else you should explain.
So we know you have some kind of LCD and an eap8266 and that's all you've given me. And I'm supposed to know what code you need to do some as yet unnamed thing just from that? Are you serious?
Or you can just keep being combative and get nowhere. I'm stuck at an airport so I honestly have nothing better to do. So I really don't care.
omfg, soooooooo many questions and they are dumb ones! its a standard means theres no model number no make nothing just google standard 16,2 arduino lcd kit and it dont matter they are all same except mine has i2c board again a standard thing look for the most common i have that, simples! h/w dont even matter its a software thing!
Sorry, but all lcds are not the same. They really aren't. And there's no such thing as a "standard" one.
But that's not the really big question. The real question is about what the code is doing with this serial data and what's being put on the LCD.
I'm not being obtuse. I honestly don't know what it is that you're trying to do with this code. I can tell you I've never had a problem writing stuff to any LCD.
But hey, if you don't want to answer these things then don't. I can tell you that you won't get a solution that way but that's your prerogative.
Actually, come to think of it I'm pretty much done with this. You're combative, don't want to answer simple questions, and you called me an ugly name. So I'm out. Maybe if you post some details someone else will help you. But as for me I'm pretty much done with you. A slightly different tact on your end and you'd have working code by now. But you're just a waste of time I think. Good luck figuring it out.