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
<[email protected]> Folgendes geschrieben:
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
<[email protected]> Folgendes geschrieben:
Hi Kiste, I will come back with a logic capture but not today.
In my example, between the last transmittedbyte (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
On Sun, Oct 17, 2021 at 2:50 PM 'Oliver Seitz' via jallib
<[email protected]> wrote:
Hi!
What do you mean by latency?
pin_a0=low_usec_delay(10)pin_a0=highTXREG=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
<[email protected]> Folgendes geschrieben:
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,
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qvKuyD2XfvBv0Fa6psQA4ZODGun8bAf4LGqzBJeT8wQXQ%40mail.gmail.com.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/692034824.1959376.1634471334015%40mail.yahoo.com.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qtSvoE8zGUJzLzPymC-KKx68vt5QDyzie8_dWotUPQyxA%40mail.gmail.com.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/331228318.1990449.1634489900666%40mail.yahoo.com.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/1303435767.2049837.1634535213167%40mail.yahoo.com.
