RS232 bug or not ?

[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 5223 times

management "hardward" is NOK

rs232_hard_bug.gif (8.84 KiB) Viewed 5223 times

management "hardward" with 1ms tempo (is OK)

rs232_hard_ 1ms.gif (8.71 KiB) Viewed 5223 times

[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

[cubitus54]

hello,

Sorry, I have not managed to reproduce the defect.
Maybe a error on my part.

[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

[cubitus54]

Hello,

I still have a problem of time lag.
UART with hardware

rs232_hard.gif (13.4 KiB) Viewed 5090 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 5090 times

In addition, I can not handle receiving ACK ...

The function that generates the frame to call "pixel"

Ecran_4D.fcf

(66.92 KiB) Downloaded 291 times

[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.

[cubitus54]

Hello, and thank you for your reply.

I rewrote the function ACK that handles the reception and it works well.

Ecran_4D.fcf

(61.98 KiB) Downloaded 343 times