You could call the init procedure each time, it would reset both the read and the write pointer, which would be what you need to "properly abuse" the library.
This library has no other purpose than "echoing a char" when the main program is ready to receive it. One could, of course, write another library for, say, string input, with the purpose of collecting a number of bytes. Greets,Kiste Gesendet von Yahoo Mail auf Android Am Fr., Jan. 15, 2021 at 11:24 schrieb vsurducan<[email protected]>: Ok, thanks this is the reason I've asked for the example "test_queue_isr.jal" which is not available in the jalpack or I didn't see it, presuming test_queue_isr.jal is an example of how this library can be used properly...with something more substantial than echoing a char. I know "_expression" is an internal variable of the library...I've reset the reading pointer and the result is the one I've described. That led me to believe there is a bug in the library which I do not understand or I'm using the library in a wrong way. I've solved the problem by modifying the serial receive interrupt handler routine for my own purpose (I've done this each time I used it over the time), but other users might see the same issue someday. thx, On Fri, Jan 15, 2021 at 11:03 AM 'Oliver Seitz' via jallib <[email protected]> wrote: Hi, _serial_rcvbuf starts with an "_", that means it is an internal variable which you shouldn't use inside your main program. Read the bytes with one of the provided methods (*not* starting with an "_") like serial_hw_read() or serial_hw_data, that way the library can take care of the order of the bytes. _serial_rcvbuf is a ring buffer, if you really insist on reading directly from there, you need to respect and modify the read and write pointers. If you need a string within your main program, the usual way would be to read from the library byte-by-byte and transfer the content from the (library-managed transparent) receive buffer to the main-program buffer. Greets, Kiste Am Freitag, 15. Januar 2021, 09:22:17 MEZ hat vsurducan <[email protected]> Folgendes geschrieben: Hi Oliver, Both programs work, serial hardware and serial_hw_int_cts. I have one master and four addressable slaves. Master sends an address via serial hardware. Addressed slave is sending two words via serial hardware. Master is receiving the four bytes via _serial_receive_interrupt_handler(). The problem is that the four bytes position in the _serial_rcvbuf is changing at each receiving sequence. To be more clearer: assuming I send continuously for debug purpose 1F 2F 3F 4F, I receive the following: first time: 1F 2F 3F 4F second time : 2F 3F 4F 1F third time: 3F 4F 1F 2F fourth time: 4F 1F 2F 3F and so on I recall I've seen this issue each time I used the serial_hw_int_cts. thanks, On Fri, Jan 15, 2021 at 9:07 AM 'Oliver Seitz' via jallib <[email protected]> wrote: > Hi Vasile, > > the serial_hw_int_cts library is supposed to be used just like > serial_hardware. The only advantage is that transfers are done "in the > background", without blocking the main program. > > Does your program work if you use serial_hardware? > > Greets, > Kiste > > > Am Freitag, 15. Januar 2021, 07:59:45 MEZ hat vsurducan > <[email protected]> Folgendes geschrieben: > > > > > > Hello, > I have never been able to use serial_hw_int_cts library as is. If I tried to > receive repeatedly a string of data, data has a different position in the > string after each reception, it's shifted. To solve the issue I was forced to > count received chars in the string and force data to stay in the counted > position... > I presume I'm using the library in the wrong way. > The _serial_receive_interrupt_handler() has a notice: "-- > serial_receive_wedge is used in test_queue_isr.jal" but the file > test_queue_isr.jal is not available in the jalpack... Do I miss something or > indeed this sample is missing? > thank you, > Vasile > > > > > -- > 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%2Bj4qv4GXyxgwGMJpxVzt%3D%2B2HKbHvoG39MnB6qTCPnOc%2B2mpw%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/786792492.210890.1610694414336%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%2Bj4qsJMhP7BkPjhGHqkE0d-RTz3KGcFQ9HvVL1P0EfTc1F2A%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/2131855630.226808.1610701407846%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%2Bj4qvm%3DJycn0U1WL-FV%3Dnbtwwa6jKZAUw4_gV7t3NZ1kZF0w%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/1017434442.257207.1610711206687%40mail.yahoo.com.
