Re: [jallib] Help about serial_hardware library for the 16F18313
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 rob...@hotmail.com wrote: > Hi Kiste, > > I fully agree with you. Not worth to add a timeout. > > Kind regards, > > Rob > > -- > *Van:* 'Oliver Seitz' via jallib > *Verzonden:* zondag 15 mei 2022 17:33 > > *Aan:* jal...@googlegroups.com > *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=1 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 > 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 > *Verzonden:* zondag 15 mei 2022 15:46 > *Aan:* jal...@googlegroups.com > *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 > 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
[jallib] [jallib build] buildbot success in jallib on jallib-standard
Hi guys, This is buildbot speaking. I have finished a build of jallib-standard on jallib. Buildslave for this Build: sebbot Build Reason: Build Source Stamp: HEAD Blamelist: rob.jansen Build succeeded! Logs are attached. sincerely, -The Buildbot -- 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 jallib+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/E1nqHAO-00020X-Bp%40casadeyork.com. Updating '.': UU CHANGELOG UU include/peripheral/timer/timer0_isr_interval.jal Updated to revision 3827. 2729 samples to validate... 1120 libraries to validate... All files validated :) Environment config JALLIB_ROOT=/home/mattschinkel/jallib/slave/standard/build JALLIB_REPOS=/home/mattschinkel/jallib/slave/standard/build/include JALLIB_SAMPLEDIR=/home/mattschinkel/jallib/slave/standard/build/sample JALLIB_JALV2=/home/mattschinkel/bin/jalv2 JALLIB_PYTHON=python2.7 Time duration: 237 secs jal jalv25r6 (compiled Oct 29 2021) Required parameter to hex is missing! no source file, use /home/mattschinkel/bin/jalv2 --help for help Error while compiling file (status=1). See previous message. 2729 samples to compile... All samples compile :) Environment config JALLIB_ROOT=/home/mattschinkel/jallib/slave/standard/build JALLIB_REPOS=/home/mattschinkel/jallib/slave/standard/build/include JALLIB_SAMPLEDIR=/home/mattschinkel/jallib/slave/standard/build/sample JALLIB_JALV2=/home/mattschinkel/bin/jalv2 JALLIB_PYTHON=python2.7 Time duration: 1773 secs
Re: [jallib] Help about serial_hardware library for the 16F18313
Hi Kiste, I fully agree with you. Not worth to add a timeout. Kind regards, Rob Van: 'Oliver Seitz' via jallib Verzonden: zondag 15 mei 2022 17:33 Aan: jallib@googlegroups.com 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=1 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 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 Verzonden: zondag 15 mei 2022 15:46 Aan: jallib@googlegroups.com 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 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 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
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 loopend 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=1 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 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_pinloop 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 Verzonden: zondag 15 mei 2022 15:46 Aan: jallib@googlegroups.com 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 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 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
Re: [jallib] Help about serial_hardware library for the 16F18313
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 Verzonden: zondag 15 mei 2022 15:46 Aan: jallib@googlegroups.com 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 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 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,
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 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 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=1If 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 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
Re: [jallib] Help about serial_hardware library for the 16F18313
Hi!
You're sending 0x40 ("@"), you're receiving (usually) 0x80, that's a bit
weird... Thinking about it, in reverse polarity a single byte with only bit 6
set should not be received at all. It was a bad idea to transmit "@". This
would be more helpful:
forever loop serial_hw_data=0x22 serial_hw_data=0x22 delay_1s(1)end loop
This would result in 0x84, followed by 0x8c with framing error when received in
opposite polarity.
Am Sonntag, 15. Mai 2022, 13:29:25 MESZ hat flyway38
Folgendes geschrieben:
Hi again,
Here's what that code produces in Termite;
80 €
80 €
c0 À
80 €
80 €
80 €
80 €
80 €
80 €
c0 À
80 €
80 €
80 €
80 €
80 €
80 €
80 €
80 €
80 €
c0 À
80 €
80 €
80 €
80 €
c0 À
80 €
Anyways, using BAUDCON1_SCKP=1 after "seral_hw_init()", I get undefined error
at compiling. But I checked target file and exchanged it to;BAUDCON_SCKP=1and
it compiles ok.This way I get Frame Error mixed with Break Error... in
receiving software.
Thank you for help.Anymore ideas?Thank you very much.
Cheers,Filipe Santos.
On Sunday, May 15, 2022 at 12:06:52 PM UTC+1 flyway38 wrote:
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=1If 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
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
Re: [jallib] Help about serial_hardware library for the 16F18313
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 > 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 > 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
Re: [jallib] Help about serial_hardware library for the 16F18313
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 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=1If 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 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
Re: [jallib] Help about serial_hardware library for the 16F18313
Hi again, Here's what that code produces in Termite; 80 € 80 € c0 À 80 € 80 € 80 € 80 € 80 € 80 € c0 À 80 € 80 € 80 € 80 € 80 € 80 € 80 € 80 € 80 € c0 À 80 € 80 € 80 € 80 € c0 À 80 € Anyways, using BAUDCON1_SCKP=1 after "seral_hw_init()" , I get undefined error at compiling. But I checked target file and exchanged it to; BAUDCON_SCKP=1and it compiles ok. This way I get Frame Error mixed with Break Error... in receiving software. Thank you for help. Anymore ideas? Thank you very much. Cheers, Filipe Santos. On Sunday, May 15, 2022 at 12:06:52 PM UTC+1 flyway38 wrote: > 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 >> 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
Re: [jallib] Help about serial_hardware library for the 16F18313
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
> 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 ‚ åŽöÿ
Re: [jallib] Help about serial_hardware library for the 16F18313
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=1If 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
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
Re: [jallib] Help about serial_hardware library for the 16F18313
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
> 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
[jallib] [jallib/jallib] 2fbf48: Fix of timer0_isr_interval.jal to support newer PICs
Branch: refs/heads/master Home: https://github.com/jallib/jallib Commit: 2fbf4865e4f31100541c3993baea8328b9914959 https://github.com/jallib/jallib/commit/2fbf4865e4f31100541c3993baea8328b9914959 Author: Rob Jansen <12682653+robjanse...@users.noreply.github.com> Date: 2022-05-15 (Sun, 15 May 2022) Changed paths: M CHANGELOG M include/peripheral/timer/timer0_isr_interval.jal Log Message: --- Fix of timer0_isr_interval.jal to support newer PICs -- 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 jallib+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/jallib/jallib/push/refs/heads/master/03fd24-2fbf48%40github.com.
