Hi
This problem is long for years. Fix it, pleace, UART is matter.
UART receive value 255 is not infinite wait
-
- Posts: 13
- http://meble-kuchenne.info.pl
- Joined: Wed Feb 08, 2023 3:33 pm
-
- Matrix Staff
- Posts: 1921
- Joined: Mon Dec 07, 2020 10:06 am
- Has thanked: 499 times
- Been thanked: 680 times
Re: UART receive value 255 is not infinite wait
Hello,
Please can you give us a simple example that demonstrates the problem, helps to pinpoint exactly where the issue could be, e.g. the specific chip family etc.
Please can you give us a simple example that demonstrates the problem, helps to pinpoint exactly where the issue could be, e.g. the specific chip family etc.
Regards Ben Rowland - MatrixTSL
Flowcode Online Code Viewer (Beta) - Flowcode Product Page - Flowcode Help Wiki - My YouTube Channel
Flowcode Online Code Viewer (Beta) - Flowcode Product Page - Flowcode Help Wiki - My YouTube Channel
-
- Posts: 13
- Joined: Wed Feb 08, 2023 3:33 pm
Re: UART receive value 255 is not infinite wait
The problem is available on Attiny85 (dec. 2023) and STM32F051C8T6 (sept. 2024), updated FC10.
-
- Matrix Staff
- Posts: 1921
- Joined: Mon Dec 07, 2020 10:06 am
- Has thanked: 499 times
- Been thanked: 680 times
Re: UART receive value 255 is not infinite wait
Hello,
The wait forever should be working on those chip families, I've just had a look through the code and it looks ok to me.
Do you have pull up resistors on the RX pin so the pin defaults high when nothing is connected? If the pin is disconnected and allowed to float then this could potentially allow for invalid data to be detected.
Can you attach your program and we can investigate further and maybe also suggest changes to your program so it doesn't need the wait forever and instead looks for valid data which should make it more robust.
To attach a project file to the forums select full editor and then there is an attachments tab under the text edit field.
The wait forever should be working on those chip families, I've just had a look through the code and it looks ok to me.
Do you have pull up resistors on the RX pin so the pin defaults high when nothing is connected? If the pin is disconnected and allowed to float then this could potentially allow for invalid data to be detected.
Can you attach your program and we can investigate further and maybe also suggest changes to your program so it doesn't need the wait forever and instead looks for valid data which should make it more robust.
To attach a project file to the forums select full editor and then there is an attachments tab under the text edit field.
Regards Ben Rowland - MatrixTSL
Flowcode Online Code Viewer (Beta) - Flowcode Product Page - Flowcode Help Wiki - My YouTube Channel
Flowcode Online Code Viewer (Beta) - Flowcode Product Page - Flowcode Help Wiki - My YouTube Channel
-
- Posts: 13
- Joined: Wed Feb 08, 2023 3:33 pm
-
- Posts: 13
- Joined: Wed Feb 08, 2023 3:33 pm
Re: UART receive value 255 is not infinite wait
Bump.
I really want do a new project with UART.
I really want do a new project with UART.
- Attachments
-
- vent-2023.fcfx
- (23.88 KiB) Downloaded 45 times
-
- Valued Contributor
- Posts: 1510
- Joined: Thu Dec 03, 2020 10:57 am
- Has thanked: 351 times
- Been thanked: 537 times
Re: UART receive value 255 is not infinite wait
Hi
I've only had a very brief look at your chart and I think you could modify to do as you wish without relying on the UART timeout. You have to use a software UART on that chip, so if the receive was on INT0 you could simply use an interrupt to catch any incoming data which frees up your uC to do other tasks rather than sitting waiting on an input.
I don't have that chip to test with, but if/when I get a chance I'll give an example.
Regards
I've only had a very brief look at your chart and I think you could modify to do as you wish without relying on the UART timeout. You have to use a software UART on that chip, so if the receive was on INT0 you could simply use an interrupt to catch any incoming data which frees up your uC to do other tasks rather than sitting waiting on an input.
I don't have that chip to test with, but if/when I get a chance I'll give an example.
Regards
-
- Valued Contributor
- Posts: 1510
- Joined: Thu Dec 03, 2020 10:57 am
- Has thanked: 351 times
- Been thanked: 537 times
Re: UART receive value 255 is not infinite wait
Hi
In the attached I have an example of a couple of things which I hope will help.
Instead of using Connection Points to go around in circles waiting on an input, just use a loop that exits when the condition is met. Alternatively you could also use a Button Component and WaitUntilHigh (or Low).
With regards to your rs232 receive, I'm not sure I understood it. You say that Receive(Char) does not wait forever but I don't see it being triggered. How does it know that a start has been issued and to look (forever) for the Character?
I don't have your chip to test with but perhaps you could try my example and see if it helps? In it I use INT0 as the Rx pin and set an interrupt on it. When it goes low it will jump to the Rx_ISR and attempt to capture your Char.
Note that I haven't actually redone your project, just given an example of how the above might work.
Regards
In the attached I have an example of a couple of things which I hope will help.
Instead of using Connection Points to go around in circles waiting on an input, just use a loop that exits when the condition is met. Alternatively you could also use a Button Component and WaitUntilHigh (or Low).
With regards to your rs232 receive, I'm not sure I understood it. You say that Receive(Char) does not wait forever but I don't see it being triggered. How does it know that a start has been issued and to look (forever) for the Character?
I don't have your chip to test with but perhaps you could try my example and see if it helps? In it I use INT0 as the Rx pin and set an interrupt on it. When it goes low it will jump to the Rx_ISR and attempt to capture your Char.
Note that I haven't actually redone your project, just given an example of how the above might work.
Regards
- Attachments
-
- vent-2023_example.fcfx
- (16 KiB) Downloaded 51 times
-
- Posts: 13
- Joined: Wed Feb 08, 2023 3:33 pm
Re: UART receive value 255 is not infinite wait
The truth about what a read routine should look like (ignoring zero).
Everything is happening so slowly because I use this thing on my home computer.
Everything is happening so slowly because I use this thing on my home computer.
- Attachments
-
- 2025-03-16_014632.png (55.58 KiB) Viewed 1910 times
-
- Valued Contributor
- Posts: 1510
- Joined: Thu Dec 03, 2020 10:57 am
- Has thanked: 351 times
- Been thanked: 537 times
Re: UART receive value 255 is not infinite wait
Hi
I don't really see the need for your Connection Points based on your post.
You can remove them, then move your two gLCD components up to the "No" branch of your decision and it will do the same.
However each iteration will initialise your gLCD screen which is uneccessary and wastes time. You only need to do this once at the start of your program.
How does your program actually know there is incoming data to process? From your chart it looks like you only call the RecieveChar component with a timeout of 200mS. How do you know you will actually receive any character in this 200mS window of opportunity?
Once it times out (or has received something) the program follows your loop doing time consuming events such as (re)initialising the gLCD and printing. What would happen if incoming characters arrived whilst you were printing or going around your loop i.e. they arrive when you are not looking? At a relatively slow baud of 9600 that translates to around 960 characters per second or approximately one every millisecond or so. Whilst you loop initialising or whatever, many characters could arrive and be missed.
As mentioned before, it is far, far better to use an interrupt triggered on incoming data. Your chart can be busy doing whatever, then when any characters arrive you will automatically jump to process. You can for example put the received characters in a Circular Buffer for processing at your leisure, but point being without an interrupt driven capture you run an extremely high risk of missing characters.
The WiKi has many examples of using Receive Interrupts and also using the Circular Buffer and I strongly recommend you consider using them. If you get stuck with it then post what you have and we will try and help.
Regards
I don't really see the need for your Connection Points based on your post.
You can remove them, then move your two gLCD components up to the "No" branch of your decision and it will do the same.
However each iteration will initialise your gLCD screen which is uneccessary and wastes time. You only need to do this once at the start of your program.
How does your program actually know there is incoming data to process? From your chart it looks like you only call the RecieveChar component with a timeout of 200mS. How do you know you will actually receive any character in this 200mS window of opportunity?
Once it times out (or has received something) the program follows your loop doing time consuming events such as (re)initialising the gLCD and printing. What would happen if incoming characters arrived whilst you were printing or going around your loop i.e. they arrive when you are not looking? At a relatively slow baud of 9600 that translates to around 960 characters per second or approximately one every millisecond or so. Whilst you loop initialising or whatever, many characters could arrive and be missed.
As mentioned before, it is far, far better to use an interrupt triggered on incoming data. Your chart can be busy doing whatever, then when any characters arrive you will automatically jump to process. You can for example put the received characters in a Circular Buffer for processing at your leisure, but point being without an interrupt driven capture you run an extremely high risk of missing characters.
The WiKi has many examples of using Receive Interrupts and also using the Circular Buffer and I strongly recommend you consider using them. If you get stuck with it then post what you have and we will try and help.
Regards