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=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 <[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.
--
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.
--
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.
--
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/120885092.1935952.1652614853977%40mail.yahoo.com.
