library latency

[vsurducan]

Hi all, just an info.

Serial_hw_write library seems to  add a quite large latency for the real signals. For example the following instructions:
serial_hw_write (address)
serial_hw_write (dataH)
serial_hw_write (dataL)
;_usec_delay ( 100 )
compiled on a 32MHz clock microcontroller are adding a measurable latency of about 80uS which seems a bit weird.

If those instructions are chained in a critical time loop, a delay after those three compiler instructions is mandatory, without it, the communication may freeze. Actually this delay includes the communication latency. I've used a logic analyzer to understand that behavior.

best wishes,

[Oliver Seitz]

Hi!

What do you mean by latency?

pin_a0=low

_usec_delay(10)

pin_a0=high

TXREG=255

The time which the serial start bit is delayed more than 1 Tcy I would call latency. The time that follows then is the time required for transmission, which is at least 10/baudrate (8 data plus 1 start plus 1 stop bits).

The first byte written to TXREG is going right through to the Transmit Shift Register (TSR), while the second byte stays in the (user accessible) TXREG, going automatically to TSR once that is free. If you want to send a third byte, the library has to wait for TXREG to be free, or data would be overwritten and lost.

So yes, if you're sending three bytes, the library will have to delay data, either by blocking the program (serial_hardware) or by caching the data in a software buffer (serial_hw_int_cts).

I haven't seen a library induced latency before. I presume the 80uS you've seen are more related to the number of three bytes and the baudrate than to the 32MHz the controller is running on.

Greets,

Kiste 

Am Sonntag, 17. Oktober 2021, 12:12:49 MESZ hat vsurducan <vsur...@gmail.com> Folgendes geschrieben:

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/CAM%2Bj4qvKuyD2XfvBv0Fa6psQA4ZODGun8bAf4LGqzBJeT8wQXQ%40mail.gmail.com.

[vsurducan]

Hi Kiste, I will come back with a logic capture but not today.

In my example, between the last transmitted byte  (dataL) at 115200bps and the next instruction (an IO pin change) which took place after the 100us delay, I should see about 100us delay isn't it?

I see 18us, meaning the three bytes transmission itself takes longer while the delay period has already started. Interrupts are all off.

If I change that delay from 100us to 50us, the communication crashes. If I change it to 90us, it will still be ok ( the real delay exists but is only 8us).

thx

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/692034824.1959376.1634471334015%40mail.yahoo.com.

[Oliver Seitz]

The usart can hold (almost) two bytes in the transmit queue, one in the shift register which is already in transmit, and another one in the TXREG, which is waiting to be transmitted. So, when the write function accepts the third byte, the second byte has just started to transmit. If you want to wait for the transmission to really end, you have to watch bit TXSTA_TRMT, which indicates that the last byte is fully shiftet out and the shift register is empty.

Greets,

Kiste

Am Sonntag, 17. Oktober 2021, 18:22:48 MESZ hat vsurducan <vsur...@gmail.com> Folgendes geschrieben:

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/CAM%2Bj4qtSvoE8zGUJzLzPymC-KKx68vt5QDyzie8_dWotUPQyxA%40mail.gmail.com.

[Oliver Seitz]

Oh, and if you're not using interrupts and it's your intention to wait and nothing but wait, until all data is sent, then there's serial_software. It can be very handy for transmissions but it's use as a receiver is limited.

Greets,

Kiste

Am Sonntag, 17. Oktober 2021, 18:58:25 MESZ hat 'Oliver Seitz' via jallib <jal...@googlegroups.com> Folgendes geschrieben:

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/331228318.1990449.1634489900666%40mail.yahoo.com.

[vsurducan]

Kiste, you've got the issue, thx. :)

My point was that serial_hw_write and serial_hw_write_word procedures from the serial_hardware library perhaps have to check first if the previous transmission has finished... Sometimes you may forget to check the TXSTA_TRM. It's not a big issue if you do not use the TX for something else after the transmission ends, or if you do not need to put TX on high_Z after the transmission ends... Of course I'm using interrupts, I've just disabled checking the issue.

There may be a discussion about using multiple interrupts routines called by different libraries against using only one...but perhaps other times.
best wishes,

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/1303435767.2049837.1634535213167%40mail.yahoo.com.