UART "Timeout" parameter question
Moderator: Benj
-
- Posts: 502
- Joined: Wed Nov 07, 2007 6:51 pm
- Location: Antwerp Belgium
- Has thanked: 121 times
- Been thanked: 108 times
- Contact:
UART "Timeout" parameter question
I don't understand how the timeout parameter in the UART receive string works.
The way I see it, the parameter just waits until the UART has a HIGH to LOW on the RX pin, and after that waits until the number of bytes in the #bytes parameter is fetched.
I think that when it starts receive bytes it stops its time out time?
I've made a few pictures of the way this parameter can be seen.
Could you please point which one is the right one?
OPTION1 (above)(timeout2.jpg)
When there is no HIGH-LOW change on the RX pin, and the time in the timeout parameter is reached, the program resumes from where the "receive string" is started
OPTION2 (above)(timeout3.jpg)
After the timeout time is reached, the program resumes even if the amount of byte isn't reached?
OPTION3 (above)(timeout4.jpg)
If there is a HIGH-LOW change on the RX pin before the timeout time is reached, the program keeps receiving bytes until the amaount of bytes in the other parameter (NumBytes) is reached.
I think option 1 and 3?
The reason I ask this is because I'm trying to receive an amount of bytes on the RX pin (that do appear!), but can't seem to fetch them and store into a variable.
In a program I've made, I know that data will appear on the RX pin.
I start waiting a while until I know that the data is put onto the RX pin.
But, I don't seem to be able to capture these bytes and store them in a variable..
Behind the scenes people are helping me with this, but I need to be sure first that the way I think the component works is the right one.
Is there a need to flush the RX buffer when I read the RX buffer many times?
How do I flush this?
If needed, can this be put into the UART component??
The way I see it, the parameter just waits until the UART has a HIGH to LOW on the RX pin, and after that waits until the number of bytes in the #bytes parameter is fetched.
I think that when it starts receive bytes it stops its time out time?
I've made a few pictures of the way this parameter can be seen.
Could you please point which one is the right one?
OPTION1 (above)(timeout2.jpg)
When there is no HIGH-LOW change on the RX pin, and the time in the timeout parameter is reached, the program resumes from where the "receive string" is started
OPTION2 (above)(timeout3.jpg)
After the timeout time is reached, the program resumes even if the amount of byte isn't reached?
OPTION3 (above)(timeout4.jpg)
If there is a HIGH-LOW change on the RX pin before the timeout time is reached, the program keeps receiving bytes until the amaount of bytes in the other parameter (NumBytes) is reached.
I think option 1 and 3?
The reason I ask this is because I'm trying to receive an amount of bytes on the RX pin (that do appear!), but can't seem to fetch them and store into a variable.
In a program I've made, I know that data will appear on the RX pin.
I start waiting a while until I know that the data is put onto the RX pin.
But, I don't seem to be able to capture these bytes and store them in a variable..
Behind the scenes people are helping me with this, but I need to be sure first that the way I think the component works is the right one.
Is there a need to flush the RX buffer when I read the RX buffer many times?
How do I flush this?
If needed, can this be put into the UART component??
- LeighM
- Matrix Staff
- Posts: 2178
- Joined: Tue Jan 17, 2012 10:07 am
- Has thanked: 481 times
- Been thanked: 699 times
- Contact:
Re: UART "Timeout" parameter question
Hi,
Yes, it is effectively 1 and 3
The timeout is the longest gap that the component will wait before it exits the function.
The gap can be before the received characters, within the string of characters, or at the end (if the requested string length has still not been fulfilled)
The usual problem with strings is missing characters whilst doing something else in the program,
hence the use of interrupts and (circular) buffers
Yes, it is effectively 1 and 3
The timeout is the longest gap that the component will wait before it exits the function.
The gap can be before the received characters, within the string of characters, or at the end (if the requested string length has still not been fulfilled)
The usual problem with strings is missing characters whilst doing something else in the program,
hence the use of interrupts and (circular) buffers
-
- Posts: 502
- Joined: Wed Nov 07, 2007 6:51 pm
- Location: Antwerp Belgium
- Has thanked: 121 times
- Been thanked: 108 times
- Contact:
Re: UART "Timeout" parameter question
Thanks LeighM,LeighM wrote:Hi,
Yes, it is effectively 1 and 3
The timeout is the longest gap that the component will wait before it exits the function.
The gap can be before the received characters, within the string of characters, or at the end (if the requested string length has still not been fulfilled)
The usual problem with strings is missing characters whilst doing something else in the program,
hence the use of interrupts and (circular) buffers
Maybe this can be put on the Wiki also? For futher generations?
The reason I ask is that I have a flowchart that on a specific moment doesn't have to do anything else then listen to the RX pin and store the bytes it receives in a string variable.
The result varies enormously. Sometimes it stores the data in a correct way, sometimes it only stores 1 or 2 bytes.
In this project (I won't go into this too specific), there is a warning that there is data comming.
There is a pin that goes low 5ms before the data on the RX pin is available.
So what I do is monitor this pin, and wait 4ms.
Then I start a "receive string, x ms time out and NumBytes = 40".
Sometimes I capture the data correct, but most of the time the data is incorrectly stored in the string variable.
Could this be because of a RX buffer that is full?
Timing on the Arduino?
Some other problem with the receive string function?
I have tried a few million settings (*) but the result isn't stable.
I know the data is received because I can monitor this on my logic analyser.
(*) a few million is maybe slightly exaggerated
-
- Posts: 502
- Joined: Wed Nov 07, 2007 6:51 pm
- Location: Antwerp Belgium
- Has thanked: 121 times
- Been thanked: 108 times
- Contact:
Re: UART "Timeout" parameter question
I will PM this because it's quite a mess right now..LeighM wrote:Could you post the program?
This would help a lot
Thanks in advance..
-
- Posts: 502
- Joined: Wed Nov 07, 2007 6:51 pm
- Location: Antwerp Belgium
- Has thanked: 121 times
- Been thanked: 108 times
- Contact:
A strange thing I've noticed earlier.
If I receive 20bytes (9600 8N1), I suppose this would take 1.04ms/byte, so 20.8ms for these 20bytes.
But the module that is connected uses 22.8ms for these 20 bytes.
I calculated it and this is about 8700baud.
Sometimes the Nano receives these bytes well, but many times it only receives 1 or 2 bytes in it's string variable.
Could this be because the module is somewhat slower than expected?
The Arduino, when it sends data to the module it takes the normal time of 20.8ms.
How tolerant is an Arduino for difference in speed?
If I receive 20bytes (9600 8N1), I suppose this would take 1.04ms/byte, so 20.8ms for these 20bytes.
But the module that is connected uses 22.8ms for these 20 bytes.
I calculated it and this is about 8700baud.
Sometimes the Nano receives these bytes well, but many times it only receives 1 or 2 bytes in it's string variable.
Could this be because the module is somewhat slower than expected?
The Arduino, when it sends data to the module it takes the normal time of 20.8ms.
How tolerant is an Arduino for difference in speed?
- LeighM
- Matrix Staff
- Posts: 2178
- Joined: Tue Jan 17, 2012 10:07 am
- Has thanked: 481 times
- Been thanked: 699 times
- Contact:
Re: UART "Timeout" parameter question
Yes, a 10% error in baud rate would probably cause issues.
But to check this you would be better to measure the time period of the bit rate, i.e. the shortest pulse in the stream.
The additional time could be down to the device having a stop period longer than 1 bit time.
Also, if the baud rate was slightly out you would most likely get unexpected characters (garbled data) rather than the one or two characters you have in the string variable.
It would probably be a good idea to use a receive interrupt and read the byte into a circular buffer,
then print the string from the buffer.
Ah, I've just spotted something in your original stream image:
The data stream starts with 0 3 4, but these are numeric 0,3,4 not characters '0','3','4'
The UART component ReceiveString function will stop receiving on a 0 or null character (this is a string terminator).
You would be better to use your own flow that loops using the ReceiveByte function instead.
Also when you come to print data from the receive buffer any print string functions will also stop at the 0.
Hope that helps
Leigh
But to check this you would be better to measure the time period of the bit rate, i.e. the shortest pulse in the stream.
The additional time could be down to the device having a stop period longer than 1 bit time.
Also, if the baud rate was slightly out you would most likely get unexpected characters (garbled data) rather than the one or two characters you have in the string variable.
It would probably be a good idea to use a receive interrupt and read the byte into a circular buffer,
then print the string from the buffer.
Ah, I've just spotted something in your original stream image:
The data stream starts with 0 3 4, but these are numeric 0,3,4 not characters '0','3','4'
The UART component ReceiveString function will stop receiving on a 0 or null character (this is a string terminator).
You would be better to use your own flow that loops using the ReceiveByte function instead.
Also when you come to print data from the receive buffer any print string functions will also stop at the 0.
Hope that helps
Leigh
-
- Posts: 502
- Joined: Wed Nov 07, 2007 6:51 pm
- Location: Antwerp Belgium
- Has thanked: 121 times
- Been thanked: 108 times
- Contact:
Re: UART "Timeout" parameter question
Thanks Leigh,
The time between bytes seem a bit long indeed.
The bits are about 0.103ms, so this seems right for 9600baud, but the time between bytes are about 0.152ms, what seem a bit too long.
So trigger the RX with an interrupt seems the right thing to be a good path to follow.
The "0" "3" "4" aren't supposed to be received by a RX pin on the Arduino.
These are addresses for high and low address for a module, and the 4 is the channel.
These are only used by the modules to communicate with eachother.
So, circular buffer it will be.
Temperatures outside reach 34°C during daytime and will rise next days till 40°C.. I will be doing something else then playing with electronics the next days
Thanks for your help!
The time between bytes seem a bit long indeed.
The bits are about 0.103ms, so this seems right for 9600baud, but the time between bytes are about 0.152ms, what seem a bit too long.
So trigger the RX with an interrupt seems the right thing to be a good path to follow.
The "0" "3" "4" aren't supposed to be received by a RX pin on the Arduino.
These are addresses for high and low address for a module, and the 4 is the channel.
These are only used by the modules to communicate with eachother.
So, circular buffer it will be.
Temperatures outside reach 34°C during daytime and will rise next days till 40°C.. I will be doing something else then playing with electronics the next days
Thanks for your help!
-
- Valued Contributor
- Posts: 617
- Joined: Fri Jun 06, 2014 3:53 pm
- Has thanked: 184 times
- Been thanked: 195 times
- Contact:
Re: UART "Timeout" parameter question
Hi
No doubt you are enjoying some cold Belgian beers. Only lager here and whilst my least favourite, needs must..
There is no minimum nor maximum time between bytes and whilst the Start bit "could" be straight after a Stop bit they could also quite easily be a few milliseconds apart. The line "idles" high (which is same level as stop) so in reality this will not be of any concern to us as the UART will happily wait to see a start bit before doing anything. Although in saying that, just to be pedantic, if we were sending large strings of either zero's or one's the receiver "could" get out of sync requiring a pause. For your application it is extremely unlikely this will happen.
As per earlier posts above, the Rx Interrupt function and the Circular Buffer are the way to go and there are plenty of examples kicking around the help files and forum.
Regards
No doubt you are enjoying some cold Belgian beers. Only lager here and whilst my least favourite, needs must..
There is no minimum nor maximum time between bytes and whilst the Start bit "could" be straight after a Stop bit they could also quite easily be a few milliseconds apart. The line "idles" high (which is same level as stop) so in reality this will not be of any concern to us as the UART will happily wait to see a start bit before doing anything. Although in saying that, just to be pedantic, if we were sending large strings of either zero's or one's the receiver "could" get out of sync requiring a pause. For your application it is extremely unlikely this will happen.
As per earlier posts above, the Rx Interrupt function and the Circular Buffer are the way to go and there are plenty of examples kicking around the help files and forum.
Regards
-
- Posts: 502
- Joined: Wed Nov 07, 2007 6:51 pm
- Location: Antwerp Belgium
- Has thanked: 121 times
- Been thanked: 108 times
- Contact:
Re: UART "Timeout" parameter question
No shortage on beers here chipfryer I think you are a bit jealous
I've never used the CB before, but my first experience look good.
I can store the received RX data in a variable, the only thing that is left to solve is that the last byte appears double in the variable.
But that won't be a great problem to solve.
I'm still recovering after a few days of heat >39°C, so I will damage my brain some more with nice liquids (on which you are so keen on)
I've never used the CB before, but my first experience look good.
I can store the received RX data in a variable, the only thing that is left to solve is that the last byte appears double in the variable.
But that won't be a great problem to solve.
I'm still recovering after a few days of heat >39°C, so I will damage my brain some more with nice liquids (on which you are so keen on)
-
- Valued Contributor
- Posts: 617
- Joined: Fri Jun 06, 2014 3:53 pm
- Has thanked: 184 times
- Been thanked: 195 times
- Contact: