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
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=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 < > [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 > <https://groups.google.com/d/msgid/jallib/CAM%2Bj4qvKuyD2XfvBv0Fa6psQA4ZODGun8bAf4LGqzBJeT8wQXQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > 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 > <https://groups.google.com/d/msgid/jallib/692034824.1959376.1634471334015%40mail.yahoo.com?utm_medium=email&utm_source=footer> > . > -- 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.
