If I setup the baud rate greater than 9600, then, when i open the Serial Monitor I'm seeing a strange character right at the beginning of the window: ý or ø or others similarly with these ones. The baud rate in the setup() it's exactly the same with the one in the Serial Monitor.
Also, in the Serial Monitor, if I send over 70 characters at a baud rate of 9600, or over 180 characters at a baud rate of 115200, then, I can get only 70 characters or maximum 180 characters, depending on the baud rate. Where are the other characters=bytes that I have send? Is this because the internal buffer of 64bytes works independently of the loop() function? So while the loop() executes different things and consumes some time, the buffer is still working without to care for loop() ? Cause in this case, if I make a string to work as a buffer and capture the bytes from the serial port, wouldn't be useless since the loop() can't keep up with the internal buffer of 64bytes?
This is the code:
Try using Serial.write(Serial.read()); instead.
You will get all the bytes back.
You will overrun the 64 byte serial buffer eventually, using Serial.writeln, because you are printing the ASCII values in decimal of the bytes you send, and not the characters you sent. This means that for each character you send, you will get at least 4 characters.. two decimal digits, plus a CR/LF.
It gets worse if you send with Serial Monitor set to send line endings.
So, the Serial.write() is a more faster function than Serial.print() ?
For one character, as a character, yes. If you want to send an int as a string, for instance, you have to use the print() method.
The question really should have been "So, write() is faster than println()?". And, of course, the answer is that write() is faster because it sends one byte without conversion, while println() is sending a minimum of 3 bytes, so it takes a minimum of three times as long.
If my loop() function takes 2 seconds to be executed once, then all I read from the internal serial buffer, is the last byte entered. All the other bytes are gone. Ok, let's say I can read all the buffer, but there are still 400-64=336 bytes gone forever. And if I increase the baud rate, then everything gets worse, because that means I have to reduce somehow the time consumed by loop() in one execution.
So, from my point of view, there is an inconsistency between the serial speed and the loop() execution speed. Even if I manage to optimize the loop() to be executed in 0.1 seconds, that won't change a lot: the huge speed of the serial port it's wasted.
What's this all about?
I want to receive Morse code from the serial port and output it as text on a PC. And the speed of the incoming bytes is somewhere between 5kB/s and 10kB/s. So a baud rate of 115200 should be enough. But the loop() function can't keep up with this speed.
Then I found a trick: right at the beginning of the loop() I put a While() function, and inside of it, with the Serial.read() function I start to write the bytes into a string (the time needed for the While() to be executed once is far far shorter than the one loop() needs to be executed once). And when I receive -1, the While() function ends and the conversion of the bytes from the string, into text, begins.
But the problem is that I don't receive only 10 kB, and that's it. After a few moments, another set of 5-10 kB comes, and so on. So while the Arduino converts the bytes into text and write the text obtained to PC, other bytes cross the internal serial buffer without I make use of them.
If my loop() function takes 2 seconds to be executed once, then all I read from the internal serial buffer, is the last byte entered. All the other bytes are gone.
It's clear, then, that loop() should not take 2 seconds to complete. What does it? If there are any delay() calls, get rid of them.
So, from my point of view, there is an inconsistency between the serial speed and the loop() execution speed.
The loop() function should not take anywhere near that long. The loop() function should iterate several times per millisecond. Each byte of serial data takes several microseconds to arrive, so reading all that have arrived during an iteration of loop() should, assuming loop() is called often enough, prevent overflow of the serial buffer.
Why are you sending 400 bytes without handshaking?
Those 2 seconds were an hypothetic case, to underline a principle and, with your help, to see if I am right.
So thanks! All the answers were helpful.
But in your last answer, if a byte needs, let's say 10 microseconds, to arrive (of course, it depends on the speed and on the number of errors occured, but let's say we don't have any errors now), and the loop()is executed in 0.1 miliseconds, there would still be an inconsistency. Some bytes will not be read by the Serial.read().
By shaking hands, you mean to negociate with the sender? So after I have received x agreed bytes, he can send me the next x bytes?
But in your last answer, if a byte needs, let's say 10 microseconds, to arrive (of course, it depends on the speed and on the number of errors occured, but let's say we don't have any errors now), and the loop()is executed in 0.1 miliseconds, there would still be an inconsistency. Some bytes will not be read by the Serial.read().
Enough of the hypothetical scenarios. Let's talk about your project.
By shaking hands, you mean to negociate with the sender? So after I have received x agreed bytes, he can send me the next x bytes?
Yes. Just like a conversation. The Arduino says "Ready". The other device sends some data. The Arduino collects it, processes it, does something with it, and says "Ready" again.
student_student:
if a byte needs, let's say 10 microseconds, to arrive (of course, it depends on the speed and on the number of errors occured, but let's say we don't have any errors now), and the loop()is executed in 0.1 miliseconds, there would still be an inconsistency. Some bytes will not be read by the Serial.read().
That's true, but if you look at the timing you've described you'd need to be running the serial line at around 1,000,000 bps which is obviously unrealistic.
In a sensible, credible setup the Arduino is capable of reading the incoming serial data orders of magnitude faster than it arrives - as long as you design your sketch correctly so that it doesn't spend extended intervals ignoring the serial port.
I want to receive Morse code from the serial port and output it as text on a PC. And the speed of the incoming bytes is somewhere between 5kB/s and 10kB/s. So a baud rate of 115200 should be enough. But the loop() function can't keep up with this speed.
Morse code over the serial port? What sort of format is this, and how does anyone send 5-10k bytes/second?
You seem to be saying that you want to be able to receive and pass on 10K bytes/second. Since 115200 baud is approximately 11,520 bytes/second, you will not want to be doing very much other processing. You really should expand on what you are actually doing, preferably with a description of the input and processing required, and preferable in the form of Arduino code.
Yes, if I output those 5-10kB for a human, then it's a huge speed to keep up (maybe for an alien...).
(this was the case I have mentioned before, were the loop() gets executed in a few seconds or even minutes - human case).
But for a computer, there's no problem.
Let's forget about converting the bytes into text and print them on the PC. If I just want to pass them further to an antenna, then everything becomes simple, cause all I have to do is to read the byte from position nr.1 of the buffer, with Serial.read(), and tell Arduino how to ouput it (a few digitalWrite()'s and delay()'s). Except one thing. If the loop() is now faster than the serial speed, how can i know I'm not reading the same byte that was read in previous loop() ?
So, to conclude everything, is there a way to synchronize the loop() with the serial speed? Or, at least to know when I receive a new byte?
Like the following two examples:
void loop() void loop()
{ {
x = Serial.read(); ...something time consuming...
y = Serial.read(); z = Serial.read();
} }
In the first case, how can i know y don't gets the same byte like x did? - because the speed of calling two consecutive Serial.read() could be greater than the speed of serial transmission.
In the second case, how can I know that in every loop(), z gets the next byte received in the buffer, and not the third or fifth or tenth byte received? - because the speed of loop() could be lower than the speed of serial transmission. ** a good idea is the one with the "handshaking", but just for this last case.
In the first case, how can i know y don't gets the same byte like x did? - because the speed of calling two consecutive Serial.read() could be greater than the speed of serial transmission.
The read() method removes the byte from the buffer. Calling the method pop() would have been a better choice, in my opinion.
Neither example is any good. There is a method, available(), that indicates how many bytes there are to read. Don't read more than are available.
...something time consuming...
Doesn't belong in loop. Restructure the code to be non-blocking. Or, forget speed and deal with lost serial data. Your choice.
Now it makes sense. I didn't know that Serial.read() deletes the byte from the buffer after reading it. There's no such thing in the Reference page.
Where can i found others things like that, about functions? Things that are not mentioned in the Reference page?
It's probably not mentioned because it's not only pretty standard to remove something from a buffer when you read it. I suppose it should have been mentioned to help beginners, though.
That being said, there are two major hints in the reference page for Serial. One is the example sketch for Serial.read(), where no bytes are explicitly removed from the buffer. The second is the Serial.peek() function, that says:
peek()
Returns the next byte (character) of incoming serial data without removing it from the internal serial buffer. That is, successive calls to peek() will return the same character, as will the next call to read(). peek() inherits from the Stream utility class
