Clearing serial buffer solved

multimedia:
Im a noob at c

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.

And don't call people ugly names.

i dam well just told you lcd 16,2 standard arduino kit screen thats it and esp 8266

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!

Hardware determines how you write the software.

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.

no the ide compiles depending on options! just give me code and i will test :slight_smile: plz

Riva:
Would it be better to write a small function to clear the buffer instead of doing serial.end/serial.begin as this may fragment memory.

void serialFlush(){

while(Serial.available() > 0) {
    char t = Serial.read();
  }
}

Hi, Can you please explain how will this line of code empty the serial buffer?

void serialFlush(){

  • while(Serial.available() > 0) { //while there are characters in the serial buffer, because Serial.available is >0*
  • char t = Serial.read(); // get one character*
  • }*
    *} *

I basically made an lcd display that uses a file / path requests from a form all to save having to use sd card for displaying things but want to be able to rewrite it and the program know if new input detected if yes then change sort of thing but im novice and not got a clue the best way to do this, it sort of works but not stangle due to after a long while it clears itself anyone help?

What's your native language OP?

irrelevent stick to the topic!

multimedia:
irrelevent stick to the topic!

Relevant, beccause you aren't making much sense when you type and I thought if you are not a native English speaker I would help you find the forum where they speak your language.

If English is your native language then please take a little more care when you type to make something that is readable by others. Incude maybe some punctuation or something. You're asking a bunch of professionals for help, you're not typing a text message to your boyfriend. Try to look at least mildly intelligent if you want anything other than the dregs to try to help you.

2 Likes

aditya123:
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 , [...].

Unfortunately, I could never figure out the meaning/significance ofemptying the serial buffer.

A: Emptying the Serial Buffer of the Receiver Section
Data comes to the receiver one character at a time. When the character arrives, it is immediately read upon and is saved in an user defined array. If so, how a serial buffer can get full and such we need to empty/flush it after reading the data. It is only one byte long buffer as I understand. If we don't read the character that has just arrived, there is a possibility that the character byte might be overwritten by the arrival of the next character. Therefore, the speed of data read must be higher than the speed (the Bd) at which data arrives.

B: Serial Buffer of the Transmit Section.
In UART Protocol, one character is transmitted at a time. If so, the execution of the command Serial.print("Arduino"); requires that there should be an intermediate buffer to hold the characters of the message Arduino. As I understand, the transmission of Serial.print("Arduino"); is composed of the following 7 sub transmissions:

Serial.print('A');
Serial.print(r');
Serial.print('d');
Serial.print('u');
Serial.print('i');
Serial.print('n');
Serial.print('o');

How much (in byte) is the length of the serial buffer of the Transmit Section?

Both buffers are 64 bytes on most boards.

It's defined in HardwareSerial.h

#if !defined(SERIAL_TX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_TX_BUFFER_SIZE 16
#else
#define SERIAL_TX_BUFFER_SIZE 64
#endif
#endif
#if !defined(SERIAL_RX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_RX_BUFFER_SIZE 16
#else
#define SERIAL_RX_BUFFER_SIZE 64
#endif
#endif
#if (SERIAL_TX_BUFFER_SIZE>256)
typedef uint16_t tx_buffer_index_t;
#else
typedef uint8_t tx_buffer_index_t;
#endif
#if  (SERIAL_RX_BUFFER_SIZE>256)
typedef uint16_t rx_buffer_index_t;
#else
typedef uint8_t rx_buffer_index_t;
#endif

Delta_G, it is just an academic query:

If the buffer size of the Transmit Section is 64 byte, only 64 characters of the following message should be transferred and the remaining characters are either lost or queued somewhere. Practically, it is observed that the whole text has appeared on the Se rail Monitor.

Serial.println("//put your setup code here, // put your setup code here, to run once: // put your setup code here, to run once: // put your setup code here, to run once:");

Yes, print will block if the buffer is full. cant post the code from print.h right now but it's there.

This is the reason Serial print from an interrupt is so dangerous. Nothing leaves the buffer because the interrupts are off and print deadlocks waiting for room in the buffer.

Delta_G:
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.

I'm gonna call you on this. You shouldn't be calling scenarios like that stupid, making him feel bad.

I present a simple counter-example:
Random data which made its way through 8N1 encoding when your RX receiver was listening to data on a bus intended for another receiver.

This is the case in my project, and I'm not doing something 'stupid'. I'm using a single wire for both RX and TX, and when in RX, the baud rate is different from the TX baud rate. Some times you need to send out a command to change TX properties and reinitialize your receiver, clearing prior data you know is junk.

I too was looking for a simple method to clear the input buffer aside from a while loop.

Random data which made its way through 8N1 encoding when your RX receiver was listening to data on a bus intended for another receiver.

If you are throwing out the whole buffer, how do you know where the random data ends and the good data starts? I'll say it again, throwing away data without knowing what it is that you are throwing away is foolish. I'm sure you'll find some corner case where it makes sense to you, but it is still foolish from a design perspective.

If your receiver is picking up random garbage from some other bus that it wasn't supposed to be listening to then you have a design issue, not a need to throw away data.

In my case the lcd screen only holds x number of chars, so all good i wana be able to clear it to then print new input when thats the case but not if no new input comes in.

Delta_G:
If you are throwing out the whole buffer, how do you know where the random data ends and the good data starts? I'll say it again, throwing away data without knowing what it is that you are throwing away is foolish. I'm sure you'll find some corner case where it makes sense to you, but it is still foolish from a design perspective.

If your receiver is picking up random garbage from some other bus that it wasn't supposed to be listening to then you have a design issue, not a need to throw away data.

If the given design dictates that you know its all garbage, then its not foolish from a design perspective. And there's no 'design issue' - theres imposed constraints.

Don't be so righteous - there is a world of scenarios out there you haven't heard of and likely won't. You're not going to win this one - just take it on the nose that you shouldn't tell people they're foolish for their choices when you have no backstory.

There is a million scenarios where you are listening to garbage but you can TX out a command to clear it. Radio encounters jokes like this all the time. Be helpful.

1 Like