Go Down

Topic: clear Serial Buffer (Read 6232 times) previous topic - next topic

lemming

#15
Dec 10, 2012, 01:33 am Last Edit: Dec 10, 2012, 01:38 am by lemming Reason: 1
Quote
"I didn't need this; why did they bother?"


As I mentioned, I'm not fussed by it but I was curious why they went to the effort when they have enough on their plate to do without taking this feature.  I had not seen any demand for it in the forums (although I may have missed it) and thought that they would be busy with other, more in demand, features. I'm not saying that because I don't use it, no-one else should have it.

Quote
How does what do what?

Print without blocking.

Quote
Serial output isn't happening "in the background".


I'm still not clear on how it works.... If its not blocking execution of the code after the print statement and carries on execution of the subsequent code while still completing the print statement at a later time then that would seem like a background task. Just like on single processor PCs, where multitasking is not really concurrent multitasking but just faking it with time slicing very quickly.

Quote
It could still be incomplete two weeks later.


Does this mean that we should always use a flush after a print statment?



 
EDIT:
Cross post. Lefty answered most of this while I was writing.
 




 

PaulS

Quote
Does this mean that we should always use a flush after a print statment?

Code: [Select]
Serial.print("switch state: ");
Serial.println(state);

Do I really need to block waiting for this data to get to the Serial Monitor?

lemming

#17
Dec 10, 2012, 01:42 am Last Edit: Dec 10, 2012, 01:48 am by lemming Reason: 1
Quote
Do I really need to block waiting for this data to get to the Serial Monitor?


You may if that message may not be printed for some time.

Quote
It could still be incomplete two weeks later.


In my polling sketches I do not want to waste time hanging around for response strings when the request has not been completely sent.
I want to send the request, make sure its gone, and wait for the reply knowing that it is going to come back soon so I can get on with other tasks.

PeterH


I do not want to waste time hanging around for response strings when the request has not been completely sent.


You should not be wasting time hanging around for response strings after the request has been sent, either. If you design your sketch correctly it will handle response strings as and when they arrive, and continue dealing with anything else that needs doing in the meantime.
I only provide help via the forum - please do not contact me for private consultancy.

lemming

#19
Dec 10, 2012, 05:13 am Last Edit: Dec 10, 2012, 05:15 am by lemming Reason: 1
Thanks PeterH but the "anything else that needs doing in the meantime" is sending requests to other nodes which also may or may not respond in a timely manner due to this issue. Therefore the next reply coming back may be for the most recent request or one from some time ago. I thought of using a stack to keep track, but sometimes a response will not come back (the device connected to the serial port is a radio). One may send out four requests and only get three responses. Which goes with which? I can use header records with IDs but it would be simpler to send a request and know that the ensuing response was for the just-made request: or the absence indicates a problem which can be dealt with there and then.

PaulS

Quote
I can use header records with IDs but it would be simpler to send a request and know that the ensuing response was for the just-made request: or the absence indicates a problem which can be dealt with there and then.

If you want to force asynchronous communications to follow a synchronous pattern, you are free to do so. If your code is not causing a lot of interrupts, interrupts to shift the serial data out will happen quickly. When you enter your "waiting for a reply" loop, you do not need to have held a "do nothing for a while" coffee break before hand. Part of the "waiting for a reply" time will be as a result of the last byte being shifted out. But, so what?

How impatient are you going to be, waiting for a response that is going to take orders of magnitude longer to receive than it took to shift out the last byte?

Go Up