Page 1 of 1
RS232 bug or not ?
Posted: Fri Aug 16, 2013 9:14 pm
by cubitus54
Hello,
I do not know if this is a bug.
If I make an emulated RS323 transmission, the transmission is OK
if I do the same thing with the management "hardward" time left for the transmission is too short and the transmission is false.
The solution is added after the emission of a character corresponding to a delay time of transmission.
In the example this is a loop that sends 0, 1, 2, 3, 4, 5, 6, .... 0xFF
I'm testing with a PIC 16F1847

- emulated RS323 is OK
- rs232_soft.gif (8.65 KiB) Viewed 5364 times

- management "hardward" is NOK
- rs232_hard_bug.gif (8.84 KiB) Viewed 5364 times

- management "hardward" with 1ms tempo (is OK)
- rs232_hard_ 1ms.gif (8.71 KiB) Viewed 5364 times
Re: RS232 bug or not ?
Posted: Sun Aug 18, 2013 7:15 pm
by Spanish_dude
Could you post your Flowcode file so I can take a look at it ?
It might be an error setting it's baudrate.
- Nicolas
Re: RS232 bug or not ?
Posted: Mon Aug 19, 2013 9:10 pm
by cubitus54
hello,
Sorry, I have not managed to reproduce the defect.
Maybe a error on my part.

Re: RS232 bug or not ?
Posted: Tue Aug 20, 2013 9:33 am
by Spanish_dude
If you ever have that problem again, post your Flowcode file so we can take a look at it.
I personally never had any issues with the RS232 component.
- Nicolas
Re: RS232 bug or not ?
Posted: Sun Aug 25, 2013 5:11 pm
by cubitus54
Hello,
I still have a problem of time lag.
UART with hardware

- rs232_hard.gif (13.4 KiB) Viewed 5231 times
The first CH07 pulse indicates the beginning of sending words on the line, the second pulse CH07 indicates the end of the shipment. (Ch0 is ACK receiver)
The problem is that sends continuous while the instruction is completed.
With the management software, no problem.

- rs232_hard.gif (13.4 KiB) Viewed 5231 times
In addition, I can not handle receiving ACK ...
The function that generates the frame to call "pixel"
Re: RS232 bug or not ?
Posted: Sun Aug 25, 2013 6:19 pm
by kersing
What you are seeing is normal behavior. The hardware continues to send data after the routine has finished because the routine puts the byte to send in the hardware UART and returns while the UART is still sending that byte. The software UART has to set/reset the output signals in software, so it can not return before every bit has been handled.
Regarding the ACK:
Your flowchart is currently set to software UART. This means the controller monitors the signal level of the input. However, due to the delay of 8 milliseconds in pixel, the monitoring begins far too late.
At 9600 bps there is one data byte (1 start bit, 8 data bits and 1 stop bit) every 1,04 milliseconds. As the response is almost immediate after the last byte has been transmitted your receive misses the incoming data by about 7 milliseconds.
Re: RS232 bug or not ?
Posted: Tue Aug 27, 2013 8:57 am
by cubitus54
Hello, and thank you for your reply.
I rewrote the function ACK that handles the reception and it works well.