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, On Mon, Oct 18, 2021 at 8:34 AM 'Oliver Seitz' via jallib < [email protected]> wrote: > 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 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 > <https://groups.google.com/d/msgid/jallib/CAM%2Bj4qtSvoE8zGUJzLzPymC-KKx68vt5QDyzie8_dWotUPQyxA%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/331228318.1990449.1634489900666%40mail.yahoo.com > <https://groups.google.com/d/msgid/jallib/331228318.1990449.1634489900666%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/1303435767.2049837.1634535213167%40mail.yahoo.com > <https://groups.google.com/d/msgid/jallib/1303435767.2049837.1634535213167%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%2Bj4quRmB-vndOUskxmHk-D5amgScxMsrSE_JdYuwCsAH2RwA%40mail.gmail.com.
