Hey all, Thank you very much to all. Yes, tried timeout option, but I loose alot of received data. I think that , for now (8 pin PIC), sending to pic dummy data to unlock that loop is my best option. This way works better than timeout solution under serial_software lib usage. Unless some miraculous idea comes along.. :D
Anyways, later on, will redesign this project for a bigger board and use a bigger PIC. Thank you to all once again. Kind regards, Filipe Santos. On Sunday, May 15, 2022 at 4:44:36 PM UTC+1 [email protected] wrote: > Hi Kiste, > > I fully agree with you. Not worth to add a timeout. > > Kind regards, > > Rob > > ------------------------------ > *Van:* 'Oliver Seitz' via jallib <[email protected]> > *Verzonden:* zondag 15 mei 2022 17:33 > > *Aan:* [email protected] <[email protected]> > *Onderwerp:* Re: [jallib] Help about serial_hardware library for the > 16F18313 > Hi Rob, > > the most critical thing when receiving asynchronous data, is to precisely > catch the starting edge of the start bit, as all the timing in the > following byte depends on it. > > while serial_sw_rx_pin loop > end loop > > This is in fact only two machine instructions, and therefore reacts within > 2Tcy or 2µs at 4MHz. > > I did not count the machine instructions for subtracting a dword, but I > think it must be more than 12 instructions, and another 12 for comparing to > 0. Plus the 1µs delay, plus the "&"... Will take at least 30µs at 4MHz. If > that is more than half a bit, data corruption is more than likely. > 1/60µs=16666 baud is the speed beyond that a 4MHz controller will certainly > not be able to follow anymore. > > If the transmission starts right after the timeout is over, depending on > the main program, corrupt data will be received (or a byte is completely > lost). > > Serial_software is a poor thing on the receiving side anyway. If you see > it as an improvement, go ahead. I would under all circumstances avoid using > serial_software for receiving, even more so with that timeout. > > Greets, > Kiste > > Am Sonntag, 15. Mai 2022, 16:57:09 MESZ hat Rob CJ <[email protected]> > Folgendes geschrieben: > > > Hi Kiste, Filip, > > An option would be to extend the serial_software.jal library with a > maximum wait time for reading and when a timeout occurs return a '0' as > data. > > So something like. > -- See if a timeout is defined to prevent an endless wait > if defined(SERIAL_SOFTWARE_READ_TIMEOUT) then > var dword _serial_timeout = SERIAL_SOFTWARE_READ_TIMEOUT > -- wait for startbit with timeout > while serial_sw_rx_pin & (_serial_timeout > 0) loop > _serial_timeout = _serial_timeout - 1 > _usec_delay(1) > end loop > else > -- wait for startbit without a timeout > while serial_sw_rx_pin loop end loop > end if > > -- When a timeout is defined and a timeout occcured return 0 as data. > if defined(SERIAL_SOFTWARE_READ_TIMEOUT) then > if (_serial_timeout == 0) then > data = 0 > end if > end if > > Would that work? > > Kind regards, > > Rob > > ------------------------------ > *Van:* 'Oliver Seitz' via jallib <[email protected]> > *Verzonden:* zondag 15 mei 2022 15:46 > *Aan:* [email protected] <[email protected]> > *Onderwerp:* Re: [jallib] Help about serial_hardware library for the > 16F18313 > > Hi! > > Well... 8 pin is a problem... I only have solutions which aren't that > elegant... > > > - use a different USB UART, which uses the idle high mode (which in fact > is standard on 3.3 and 5 volt levels) > - if you have an I/O pin (other than RA4) to spare, use the comparator or > a CLC to invert the signal, and connect the output and RX to that same pin > via PPS > - use external circuitry to invert the signal, like a MAX232, which is > inverting since the 1970s and therefore in fact the reason for all the > confusion ;-) > - write a new library, which receives by timers and pin-change interrupts > > Greets, > Kiste > > Am Sonntag, 15. Mai 2022, 14:56:49 MESZ hat flyway38 <[email protected]> > Folgendes geschrieben: > > > Hi Kiste, > > Understad your points. > The main issue am trying to solve while using serial_software (wich makes > my project runs good enough) is that loop while trying to receive data; > "while !serial_sw_rx_pin loop". > Because of this loop have to constantly send dummy data to allow PIC out > of the loop. > All other code runs fairly ok (somewhat sluggish, but good enough for the > needs). > Checked PIC18F14K2, the problem is I need to stick to 8pin THT PIC right > now... > On Sunday, May 15, 2022 at 12:42:01 PM UTC+1 Kiste wrote: > > Hi Filipe, > > that's an important information: seral_sw_invert defaults to "true". If > you had to set it, you have set it to "false". That means, the line you are > driving is in "idle low" mode. That mode is not supported by > serial_hardware, as it is not supported by the classical USART hardware in > PIC controllers. > > You can not cure that problem by sendig serial_hw_data=!value , as that > does not alter the polarity of start- and stopbits. > > With the delay of 300µs between bytes, you do not cure the framing error. > By doing so, you mislead the receiver to recognise data bits as framing > bits, so it's one error masking the other error. > > If you can use another PIC, like PIC18F14K22, the hardware can be set to > "idle low" mode for sending and receiving, your 16f18313 can only use the > transmission side in that mode. So, to make the receiving side work, you > would have to use additional hardware (or peripherals like CLC or > comparators) to invert incoming data. > > Greets, > Kiste > > Am Sonntag, 15. Mai 2022, 13:06:54 MESZ hat flyway38 <[email protected]> > Folgendes geschrieben: > > > Hi Kiste, > > Thak you very much for your input. > Will test your code to check and answer you. > Anyways, right now I can avoid the Framming Error but still receiving > incorrect data while using serial_hardware library. > > About framming Error, the problem was due to the way I sent data to > transmit reg. > I was sending two bytes with no delay in between (it works good like this > using serial_software lib). > But if I use a delay of about 300us between the two bytes sent, Frame > Error disppears, but as said above, received data by computer is incorrect. > Less than that delay, I get Frame Error. > > Can answer your question about "const bit serial_sw_invert". * Yes*, > needed to set this var using serial_software. > Will back here with answer for your second quest. > Thank you > > Cheers, > Filipe Santos. > On Sunday, May 15, 2022 at 10:48:19 AM UTC+1 Kiste wrote: > > That data is a bit complex for easy analysis, though I see that you've got > a repeating value every five bytes in all of the samples. The baud rate > therefore should not be the problem. > > If you want to rely on my guess, insert after "seral_hw_init()" > > BAUDCON1_SCKP=1 > If this helps for transmission, you can't use the USART directly for > receiving, as it has no inversion option for RX. In that case, you can use > a CLC or a comparator as inverter. > > > If you want to track down the error and learn how to do that, please > answer my questions: > > Have you set "const bit serial_sw_invert" with serial software? > > What is the result if you just transmit a single character with pauses? > > forever loop > serial_hw_data="@" > delay_1s(1) > end loop > > > Greets, > Kiste > > Am Sonntag, 15. Mai 2022, 11:11:09 MESZ hat flyway38 <[email protected]> > Folgendes geschrieben: > > > Hello Kiste, > > I use Termite to check what flows in my comm line. > Here's what I see and makes my project work good enough, using > serial_software (small extract): > > 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef ..íï*ñ..íï*ñ..íï > 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 *ñ..íï*ñ..íï*ñ.. > ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 íï*ñ..íï*ñ..íï*ñ > 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef ..íï*ñ..íï*ñ..íï > 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 *ñ..íï*ñ..íï*ñ.. > ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 íï*ñ..íï*ñ..íï*ñ > 09 00 ee ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef ..îï*ñ..íï*ñ..íï > 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 *ñ..íï*ñ..íï*ñ.. > ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 íï*ñ..íï*ñ..íï*ñ > 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef ..íï*ñ..íï*ñ..íï > 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 *ñ..íï*ñ..íï*ñ.. > ed ef 2a f1 09 00 ee ef 2a f1 09 00 ee ef 2a f1 íï*ñ..îï*ñ..îï*ñ > 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef ..íï*ñ..íï*ñ..íï > 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 *ñ..íï*ñ..íï*ñ.. > > Now here's what I see using serial_hardware: > > 9a f1 81 80 f5 ef 92 f1 81 80 fd ef 9a f1 81 80 šñ €õï’ñ €ýïšñ € > f5 ef 9a f1 81 80 f6 ef 9a f1 89 80 fd ef 9a f1 õïšñ €öïšñ‰€ýïšñ > 89 80 fe ef 9a f1 89 80 fd ef 9a f1 89 80 f5 ef ‰€þïšñ‰€ýïšñ‰€õï > 92 f1 81 80 f5 ef 9a f1 81 80 f5 ef 92 f1 89 80 ’ñ €õïšñ €õï’ñ‰€ > f5 ef 9a f1 81 80 f5 ef 9a f1 81 80 fd ef 9a f1 õïšñ €õïšñ €ýïšñ > 89 80 fe ef 9a f1 89 80 fd ef 9a f1 89 80 fd ef ‰€þïšñ‰€ýïšñ‰€ýï > 9a f1 89 80 f5 ef 92 f1 81 80 fd ef 9a f1 89 80 šñ‰€õï’ñ €ýïšñ‰€ > fd ef 9a f1 81 80 fd ef 92 f1 89 80 fe ef 9a f1 ýïšñ €ýï’ñ‰€þïšñ > 81 80 fd ef 9a f1 89 80 f5 ef 9a f1 81 80 fd ef €ýïšñ‰€õïšñ €ýï > 9a f1 81 80 fe ef 9a f1 81 80 f5 ef 9a f1 89 80 šñ €þïšñ €õïšñ‰€ > f5 ef 9a f1 81 80 ed ef 9a f1 81 80 f5 ef 9a f1 õïšñ €íïšñ €õïšñ > 89 80 fd ef 9a f1 89 80 f6 ef 92 f1 89 80 fe ef ‰€ýïšñ‰€öï’ñ‰€þï > 92 f1 89 80 fd ef 92 f1 81 80 fe ef 92 f1 89 80 ’ñ‰€ýï’ñ €þï’ñ‰€ > f5 ef 9a f1 81 80 fe ef 92 f1 89 80 fd ef 9a f1 õïšñ €þï’ñ‰€ýïšñ > 81 80 fd ef 8a f1 89 80 fd ef 92 f1 81 80 fd ef €ýïŠñ‰€ýï’ñ €ýï > 92 f1 81 80 fd ef 9a f1 81 80 ed ef 92 f1 89 80 ’ñ €ýïšñ €íï’ñ‰€ > > Finally, here's what I see using serial_hardware, inverted data in > serial_hw_write function ("TXREG = !data"): > > 82 90 e5 8e fe ff 82 90 e5 8e f6 ff 8a 90 ed 8e ‚ åŽþÿ‚ åŽöÿŠ íŽ > fe ff 8a 90 ed 8e fe ff 8a 90 e5 8e fe ff 89 90 þÿŠ íŽþÿŠ åŽþÿ‰ > e5 8e fe ff 82 90 e5 8e f6 ff 81 90 ed 8e f6 ff åŽþÿ‚ åŽöÿ íŽöÿ > 82 90 ed 8e f6 ff 8a 90 e5 8e f6 ff 82 90 ed 8e ‚ íŽöÿŠ åŽöÿ‚ íŽ > f6 ff 8a 90 ed 8e fe ff 82 90 e5 8e f6 ff 81 90 öÿŠ íŽþÿ‚ åŽöÿ > ed 8e f6 ff 82 90 e5 8e f6 ff 82 90 e5 8e fe ff íŽöÿ‚ åŽöÿ‚ åŽþÿ > 8a 90 e5 8e f6 ff 8a 90 e5 8e f6 ff 82 90 ed 8e Š åŽöÿŠ åŽöÿ‚ íŽ > f6 ff 82 90 e5 8e fe ff 81 90 e5 8e fe ff 82 90 öÿ‚ åŽþÿ åŽþÿ‚ > ed 8e fe ff 82 90 ed 8e fe ff 8a 90 ed 8e fe ff íŽþÿ‚ íŽþÿŠ íŽþÿ > 82 90 e5 8e fe ff 82 90 ed 8e fe ff 82 90 e5 8e ‚ åŽþÿ‚ íŽþÿ‚ åŽ > fe ff 8a 90 e5 8e f6 ff 82 90 ed 8e fe ff 82 90 þÿŠ åŽöÿ‚ íŽþÿ‚ > e5 8e fe ff 82 90 e5 8e fe ff 82 90 e5 8e f6 ff åŽþÿ‚ åŽþÿ‚ åŽöÿ > 82 90 e5 8e f6 ff 81 90 ed 8e f6 ff 8a 90 ed 8e ‚ åŽöÿ íŽöÿŠ íŽ > f6 ff 82 90 e5 8e f6 ff 8a 90 e5 8e f6 ff 89 90 öÿ‚ åŽöÿŠ åŽöÿ‰ > ed 8e f6 ff 8a 90 e5 8e fe ff 82 90 ed 8e fe ff íŽöÿŠ åŽþÿ‚ íŽþÿ > 82 90 ed 8e f6 ff 82 90 e5 8e f6 ff 82 90 e5 8e ‚ íŽöÿ‚ åŽöÿ‚ åŽ > > It seems serial_hardware is not transmitting same data. > Any help would be great. > Thank you. > > Cheers, > Filipe Santos > > On Sunday, May 15, 2022 at 6:57:39 AM UTC+1 Kiste wrote: > > Hi Filipe, > > If serial_software works with "const bit serial_sw_invert = true", then > serial_hardware should also work. serial_software supports the non-inverted > mode, the uart hardware in newer PICs also supports the non-inverted mode, > but the serial_hardware library does not yet support that mode natively. > > Have you tried single chars with time in between? > > forever loop > serial_hw_data="@" > delay_1s(1) > end loop > > This loop transmits a start bit and a single set data bit every second. > From the results you're seeing on the PC, the error might be narrowed down. > > Greets, > Kiste > > > Am Samstag, 14. Mai 2022, 22:58:28 MESZ hat flyway38 <[email protected]> > Folgendes geschrieben: > > > Hi to all, > > Have been using serial_software library with enough success until now. > Am coding for use a TTL-232R-5V-AI USB Cable to connect to computer. > Using serial_software library with invert bit activated, am getting good > results. > It all works good enough sending data to computer > The problem with this library is while receiving data from computer. As > soon as this funcion is activated in PIC code, the library locks in a loop > waiting for data. > So, started to migrate my code for use with serial_hardware library > instead, to avoid this lock. > But now I get Frame Error from COMM PORT with not usefull data, all the > time. Even if I invert data received. Have also tried different baud rates, > etc... > Can anyone help about this issue? > Thank you very much. > > Kind regards, > Filipe Santos. > > -- > 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/ac896057-cc8b-40e2-9e84-5cc7d7843640n%40googlegroups.com > > <https://groups.google.com/d/msgid/jallib/ac896057-cc8b-40e2-9e84-5cc7d7843640n%40googlegroups.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/1c5acd16-71a0-4b4f-b5a8-f156ebc81377n%40googlegroups.com > > <https://groups.google.com/d/msgid/jallib/1c5acd16-71a0-4b4f-b5a8-f156ebc81377n%40googlegroups.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/2841ae74-69b7-47ee-be97-6bee2a92cdb9n%40googlegroups.com > > <https://groups.google.com/d/msgid/jallib/2841ae74-69b7-47ee-be97-6bee2a92cdb9n%40googlegroups.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/7d84e3e6-3865-4d5d-9c1a-f8d125e72413n%40googlegroups.com > > <https://groups.google.com/d/msgid/jallib/7d84e3e6-3865-4d5d-9c1a-f8d125e72413n%40googlegroups.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/1114301196.1951990.1652622400015%40mail.yahoo.com > > <https://groups.google.com/d/msgid/jallib/1114301196.1951990.1652622400015%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/GVXP195MB1637F8C203E2069FC8861EC5E6CC9%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM > > <https://groups.google.com/d/msgid/jallib/GVXP195MB1637F8C203E2069FC8861EC5E6CC9%40GVXP195MB1637.EURP195.PROD.OUTLOOK.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/1514115999.1967130.1652628794740%40mail.yahoo.com > > <https://groups.google.com/d/msgid/jallib/1514115999.1967130.1652628794740%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/e2ba34a7-50da-42ab-b20c-4c861f08a423n%40googlegroups.com.
