Help about serial_hardware library for the 16F18313

32 views
Skip to first unread message

flyway38

unread,
May 14, 2022, 4:50:31 PMMay 14
to jallib
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.

Oliver Seitz

unread,
May 15, 2022, 1:57:39 AMMay 15
to jal...@googlegroups.com
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 <fsfo...@gmail.com> Folgendes geschrieben:


--
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+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/ac896057-cc8b-40e2-9e84-5cc7d7843640n%40googlegroups.com.

flyway38

unread,
May 15, 2022, 5:11:06 AMMay 15
to jallib
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

Oliver Seitz

unread,
May 15, 2022, 5:48:19 AMMay 15
to jal...@googlegroups.com
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 <fsfo...@gmail.com> Folgendes geschrieben:


flyway38

unread,
May 15, 2022, 7:06:52 AMMay 15
to jallib
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.

flyway38

unread,
May 15, 2022, 7:22:28 AMMay 15
to jallib
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.

Oliver Seitz

unread,
May 15, 2022, 7:42:01 AMMay 15
to jal...@googlegroups.com
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 <fsfo...@gmail.com> Folgendes geschrieben:


flyway38

unread,
May 15, 2022, 8:02:48 AMMay 15
to jallib
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...

Oliver Seitz

unread,
May 15, 2022, 8:19:32 AMMay 15
to jal...@googlegroups.com
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 <fsfo...@gmail.com> Folgendes geschrieben:


Oliver Seitz

unread,
May 15, 2022, 9:46:46 AMMay 15
to jal...@googlegroups.com
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 <fsfo...@gmail.com> Folgendes geschrieben:


Rob CJ

unread,
May 15, 2022, 10:57:20 AMMay 15
to jal...@googlegroups.com
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 <jal...@googlegroups.com>
Verzonden: zondag 15 mei 2022 15:46
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] Help about serial_hardware library for the 16F18313
 

Oliver Seitz

unread,
May 15, 2022, 11:33:20 AMMay 15
to jal...@googlegroups.com
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 <rob...@hotmail.com> Folgendes geschrieben:


Rob CJ

unread,
May 15, 2022, 11:44:36 AMMay 15
to jal...@googlegroups.com
Hi Kiste,

I fully agree with you. Not worth to add a timeout.

Kind regards,

Rob


Van: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Verzonden: zondag 15 mei 2022 17:33

flyway38

unread,
May 15, 2022, 3:20:58 PMMay 15
to jallib
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.

Rob CJ

unread,
May 16, 2022, 6:41:31 AMMay 16
to jal...@googlegroups.com
Hi Filip,

If I understand you right you use inverted serial data. In the serial software library everything - including the startbit - is inverted if you select the inverted mode. In hardware only the data can be inverted but not the startbit.

Is it not possible to add an inverter to your board so that the data is not inverted and so you can use serial hardware? You could make an inverter with one transistor and 2 resistors.

Kind regards,

Rob


Van: jal...@googlegroups.com <jal...@googlegroups.com> namens flyway38 <fsfo...@gmail.com>
Verzonden: zondag 15 mei 2022 21:20
Aan: jallib <jal...@googlegroups.com>

flyway38

unread,
May 16, 2022, 1:33:38 PMMay 16
to jallib
Hi Rob,

Yes, You're right.
And yes, will change my design for that hardware comm line inversion.
Then will back here for results or new issues :D
Thank you very much for all help.
Cheers.

Kind regards,
Filipe Santos.

flyway38

unread,
May 16, 2022, 2:22:48 PMMay 16
to jallib
Hey all,

Miracles do happen.
Maybe I have an easier way.
Am using and FTDI cable (USB - RS232/5V) and it has a configurable EEprom.
This configuration includes inversion of all RS232 signals. Have inverted RX and TX and this way am using now serial_software with that inversion bit to false.
Computer receives good data, but it seems RX on PIC side shouldn't be inverted... not receiveing good data from computer.
Can anyone confirm this? TX should be the only one to be inverted?
Thank you very much.

Kind regrads,
Filipe Santos.

flyway38

unread,
May 16, 2022, 3:27:19 PMMay 16
to jallib
Hi again,

Correction to my last post.
All working good using serial_software, with invert bit to false.
But, still Frame or Break issues in communication using serial_hardware...

Have done this Kiste test;
forever loop
   serial_hw_data=0x22
   serial_hw_data=0x22
   delay_1s(1)
end loop

and here's the results;
d7 00                                            ×.              
d5 00                                            Õ.              
d7 00                                            ×.              
d7 00                                            ×.              
d7 00                                            ×.              
d7 00                                            ×.              
d7 00                                            ×.              
d7 00                                            ×.              
d7 00                                            ×.              
d7 00                                            ×.              
d7 00                                            ×.              
d5 00                                            Õ.              
d7 00                                            ×.              
d7 00                                            ×.              
d7 00                                            ×.              
d7 00                                            ×.              
d5 00                                            Õ.              
d7 00                                            ×.              
d7 00                                            ×.              
d5 00                                            Õ.              
d7 00                                            ×.              
d5 00                                            Õ.              
d5 00                                            Õ.              
d7 00                                            ×.              
d7 00                                            ×.             

Any ideas?
Thank you very much.

Cheers,
Filipe Santos

vsurducan

unread,
May 17, 2022, 12:19:47 AMMay 17
to jal...@googlegroups.com
And voila Felipe, you find that works and your communication does not have the start bit not inverted and data inverted... :)
Congrats that you make it work!
FTD232RL datasheet says " the UART signals can each be individually inverted". The same philosophy with MAX232 where both signals need to be inverted because the chip itself has dual inverted drivers/receivers. The first step prior to writing code seems to be reading datasheets.
best wishes

vsurducan

unread,
May 17, 2022, 12:25:09 AMMay 17
to jal...@googlegroups.com
Double check if you have correct settings, baud speed, bit number, parity and stop bit. Set something like 9600, 8, N, 1 for the beginning.
Then check that your terminal is set to display the same thing as you send ( if you send hex don't expect that the terminal set for ASCII will display correct your data)...
Last, the problem might be on the computer side as well, not necessarily on the PIC...

flyway38

unread,
May 17, 2022, 6:48:35 AMMay 17
to jallib
Hi Vasile,

Thanks for the inputs here.
In fact, theres a problem about the baud rate, but this problem lets project work ok using serial_software; PIC is set for 38400 and PC port need to be set for 57600. Don't know why, but this is the way it's working for several weeks of developing...
Using serial_hardware lib, not even playing around the baud rate divergences makes it work correctly. No correct data arriving to PC or to PIC...
Big puzzle here :D
Thanks anyways.

Cheers,
Filipe Santos.

vsurducan

unread,
May 17, 2022, 7:27:05 AMMay 17
to jal...@googlegroups.com
Can you draw a schematic of your connection by hand and post it here together with a simple test code which does not run properly for you?
Mention also the operating system you're using on the computer.
Usually the problem is very simple, but impossible to see. All people here had it at least once.

Oliver Seitz

unread,
May 17, 2022, 7:31:46 AMMay 17
to jal...@googlegroups.com
Most common cause would be a wrongly set speed for compiler or controller. What are your settings?

Greets,
Kiste


Am Di., Mai 17, 2022 at 12:56 schrieb flyway38

Rob CJ

unread,
May 17, 2022, 12:42:26 PMMay 17
to jal...@googlegroups.com
Hi Filip,

This certainly looks like a timing issue especially if you need two different baudrates to get it working which is suprising to see that it does work.

The serial software library is not so strickt if you look at timing. Serial hardware samples the incoming signal and my be more strickt.

As already requested you should send a schematic diagram of your hardware. What serial hardware is used on the PC?

Kind regards,

Rob


Verzonden: dinsdag 17 mei 2022 12:48

flyway38

unread,
May 17, 2022, 1:49:11 PMMay 17
to jallib
Hi Kiste, Rob,

Thank you for your time.

My comms rig is based on a TTL-232R-5V-AI USB Cable.

My PIC Code:
Setup Segment Code;

-- PPS Setup
include pps
pps_control_lock(FALSE)                     -- unlock PPS module
RA0PPS = PPS_TX                             -- pin_A0 is TX
--RXPPS  = PPS_RA1                            -- RX is on pin_A1
pps_control_lock(TRUE)                      -- lock PPS module
--
--
--
-- ok, now setup serial
-- Transmission parameters are 8 databits, 1 stopbit, no parity, no handshake.
alias pin_TX is  pin_A0
alias pin_RX is  pin_A1
alias pin_TX_direction is pin_A0_direction
alias pin_RX_direction is pin_A1_direction
pin_RX_direction = INPUT
pin_TX_direction = OUTPUT
const serial_hw_baudrate = 38_400
include serial_hardware
serial_hw_init()
--BAUDCON_SCKP=1

RunTime Code;

     TransmitWordDataHW(mVal)
    TransmitTwoByteDataHW(0xEF, 0x2A + byte(RlyCtl))

...and;

Procedure TransmitWordDataHW(word in Data) is
   if defined(serial_hw_write) then
      var byte dx[2] at Data
      serial_hw_write(dx[1])
      delay_10us(1)
      serial_hw_write(dx[0])
      delay_1ms(5)
   end if
End procedure
--
Procedure TransmitTwoByteDataHW(byte in Data1, byte in Data2) is
   if defined(serial_hw_write) then
      serial_hw_write(Data1)
      delay_10us(1)
      serial_hw_write(Data2)
      delay_1ms(5)
   end if
End procedure

Now, VB side;

    ' setup the default comm port settings
    MSComm1.CommPort = Val(Me.Label7.Caption)
    MSComm1.RThreshold = 1                  ' use 'on comm' event processing
    MSComm1.Settings = "57600,n,8,1"        ' baud, parity, data bits, stop bits
    'MSComm1.Settings = "38400,n,8,1"
    MSComm1.SThreshold = 1                  ' allows us to track Tx LED
    MSComm1.InputMode = comInputModeBinary  ' binary mode, you can also use
                                            ' comInputModeText for text only use
    ' open the port
    MSComm1.PortOpen = True

Maybe am seeing it wrong, but it all seems ok...
And as said, it works good enough using serial_software
Any ideas?
Can also post PIC diagram if needed...
Thank you for all your efforts.

Cheers,
Filipe Santos.

Oliver Seitz

unread,
May 17, 2022, 2:05:54 PMMay 17
to jal...@googlegroups.com
Hi Filipe,


I suspect the baudrate problem in settings like

pragma target clock  ?
pragma target OSC ?
pragma target RSTOSC ?

OSCCON* = ?

What are these settings?

Greets,
Kiste

flyway38

unread,
May 17, 2022, 2:17:13 PMMay 17
to jallib
Hi again Kiste,

Here my code pragmas;

-- Pragmas/ configuration memory settings (fuses)
pragma target clock 20_000_000                   -- oscillator frequency
pragma target OSC      OFF                       -- HS crystal or resonator
pragma target RSTOSC   HFINT32                   -- power-up clock select: OSC
pragma target CLKOUTEN DISABLED                  -- no clock output
pragma target WDT      DISABLED                  -- watchdog
pragma target DEBUG    DISABLED                  -- no debugging
pragma target BROWNOUT DISABLED                  -- no brownout reset
pragma target FCMEN    DISABLED                  -- no clock monitoring
pragma target CSWEN    ENABLED                   -- allow writing OSCCON1 NOSC and NDIV
pragma target LVP      DISABLED                  -- no low voltage programming
pragma target MCLR     EXTERNAL                  -- external reset
-- The configuration bit settings above are only a selection, sufficient
-- for this program. Other programs may need more or different settings.
--
WDTCON_SWDTEN = OFF                              -- disable watchdog
--
_usec_delay (100_000)                            -- wait for power to stablilize
--
enable_digital_io()                              -- make all pins digital I/O

Cheers
Filipe Santos.

vsurducan

unread,
May 17, 2022, 2:19:01 PMMay 17
to jal...@googlegroups.com
Guys, PIC16F18313 has EUSART. Are you sure that you and Filipe are talking the same language?
What if it's just a problem of using the wrong library?
There are several ways of decreasing the error in both sw and hw serial communications, one of them is to use the "zero error" XTAL

best wishes


vsurducan

unread,
May 17, 2022, 2:19:05 PMMay 17
to jal...@googlegroups.com
Why are not using an "if-then-else" syntax instead of "while loop end loop"? 8pin PIC it's fine.

vsurducan

unread,
May 17, 2022, 2:19:07 PMMay 17
to jal...@googlegroups.com
You have to use a serial receiving procedure which uses interrupts. Read carefully the serial_hw_int_cts.jal. If new to jal, remember there is a learning curve you can not jump over it. Interrupts are not easy, usually with issues and bugs.
Good luck!

flyway38

unread,
May 17, 2022, 2:50:17 PMMay 17
to jallib
Hi Vasile,

Thank  you for your inputs.

About EUSART; How different is it? Is there any library for its better usage?
About "Zero Error" XTAL, don't know what is that. Need to lurk about it
About "if-then-else" syntax instead of "while loop end loop"; serial_software (not using RX Registers) will not wait for the start bit to know when data is incomming.
About serial_hw_int_cts; I believe it will need that signal present some where in a PIC input (not sure) to simulate CTS. I don't have that signal in my FTDI USB-RS232 converter cable. This converter only have TX, RX and GND.
Not easy for better/ hardware solutions.
Thank you anyways.

Greets,
Filipe Santos.

Oliver Seitz

unread,
May 17, 2022, 3:34:17 PMMay 17
to jal...@googlegroups.com
So, here it is:

pragma target clock 20_000_000                   -- oscillator frequency
pragma target RSTOSC   HFINT32                   -- power-up clock select: OSC

You're telling the compiler, the PIC would run at 20MHz, and you're setting the PIC to 32MHz.

Make it

pragma target clock 32_000_000                   -- oscillator frequency

and your baudrate will be as specified.

Greets,
Kiste

Am Dienstag, 17. Mai 2022, 21:12:10 MESZ hat flyway38 <fsfo...@gmail.com> Folgendes geschrieben:


--
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+un...@googlegroups.com.

flyway38

unread,
May 17, 2022, 5:17:06 PMMay 17
to jallib
Hi Kiste,

Thank you very much.
That solved the baudrate issue.

But serial_hardware still don't work as it should.
Still have Frame and Break error on PC side.

Now, your code;
forever loop
   serial_hw_data=0x22
   serial_hw_data=0x22
   delay_1s(1)
end loop

Results;
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            
b7 37 00                                         ·7.            

Cannot understand what's going on.
Anymore ideas?

Cheers,
Filipe Santos.

Matthew Schinkel

unread,
May 17, 2022, 7:03:30 PMMay 17
to jallib
You could also try internal oscillator.

Matt.

Oliver Seitz

unread,
May 18, 2022, 1:45:05 AMMay 18
to jal...@googlegroups.com
Great, that error is fixed :-)

Now here's what the PIC sends, and what I presume the PC receives:

Seq. Lvl   Pic sends   PC receives (inverted)

-3    1    idle        framing error  
-2    1    idle        framing error
-1    1    idle        framing error
 0    0    startbit    idle
 1    0    0*1+        idle
 2    1    1*2+        startbit
 3    0    0*4+        1*1+
 4    0    0*8=2       1*2+
 5    0    0*1+        1*4+
 6    1    1*2+        0*8=7
 7    0    0*4+        1*1+
 8    0    0*8=2       2*2+
 9    1    Stopbit     0*4+
10    0    startbit    1*8=b
11    0    0*1+        stopbit
12    1    1*2+        startbit
13    0    0*4+        1*1+
14    0    0*8=2       1*2+
15    0    0*1+        1*4+
16    1    1*2+        0*8=7
17    0    0*4+        1*1+
18    0    0*8=2       1*2+
19    1    Stopbit     0*4+
20    1    idle        0*8=3
21    1    idle        framing error
22    1    idle        framing error
23    1    idle        framing error
24    1    idle        framing error

You see, "b7 37" is exactly what to expect when the baudrate is correct, and the polarity is not. You just need to fix the polarity. For the transmission from the PIC to the PC you can either switch RX on the PC to non-inverted mode, or invert TX on the PIC like

BAUDCON1_SCKP=1

However, this PIC does not allow inverting its RX easily, so you need to switch the PCs TX to non-inverted mode or invert the signal by other means. That other means can be a transistor and two resistors, or a dedicated IC, even a NE555 can do it. Or, as mentioned before, if you've got an unused pin on the PIC, you can use an unused peripheral of your PIC to invert the signal.

Greets,
Kiste
   



Am Dienstag, 17. Mai 2022, 23:16:31 MESZ hat flyway38 <fsfo...@gmail.com> Folgendes geschrieben:


flyway38

unread,
May 18, 2022, 10:25:24 AMMay 18
to jallib
Hi all,

You guys are awesome.
This case is closed.
That was it. I had inverted both TX and RX in my FTDI cabe configuration.
BUT, only TX should be inverted.

Thank you VERY much guys.
This community is great.

PS:
@Matt,
Am using internal oscillator and no free pins on my PIC.

Cheers to you all!!

Best regrads,
Filipe Santos.

Rob CJ

unread,
May 18, 2022, 12:39:57 PMMay 18
to jal...@googlegroups.com
Hi Filip,

Good to see that it is solved but there is one thing I do not understand. You mentioned that the baudrate on the PC and the PIC are different in order to work.

Then I see this code:
pragma target clock 20_000_000                   -- oscillator frequency
pragma target OSC      OFF                       -- HS crystal or resonator
pragma target RSTOSC   HFINT32                   -- power-up clock select: OSC

So you define a target clock of 20 MHz (which the compiler uses for timing) but you select an internal clock of 32 MHz (which the PIC uses for timing). This mismatch will result in a mismatch of the baudrate too since serial software 'assumes' a 20 MHz clock but in fact the PIC is running on 32 MHz. Can you set the target clock to 32_000_00 and the baudrate on the PIC the same as the PC to see if that solves that problem?

Thanks

Kind regards,

Rob


Verzonden: woensdag 18 mei 2022 16:25

Aan: jallib <jal...@googlegroups.com>
Onderwerp: Re: [jallib] Help about serial_hardware library for the 16F18313

vsurducan

unread,
May 18, 2022, 12:42:04 PMMay 18
to jal...@googlegroups.com
Hi, one possibility  is to use one single inverter gate like SN74LVC1G04, one digital transistor ( base resistor connected internally) and one resistor in collector or any other already explained.
The FT232RL can invert the TX, however it seems so complicated ( it needs to program the internal eeprom, see AN121 FTDI accessing the eeprom user area) that it is much simpler to correct it in external hardware.


flyway38

unread,
May 18, 2022, 2:12:46 PMMay 18
to jallib
Hi Rob, Vasile,

@Vasile
No complicated at all to invert signals using FT_prog;
Very easy. Two clicks after installed and there you go.
You can invert any of RS232 signals, but only TX neeeded to be inverted.

@Rob
Yes. Vasile had already noticed that mistake.
It was already corrected and solved that baudrate divergence.
All fine now. Including Serial_Hardware lib is working like a charm.

Never enough to thank you all !!!
You guys rock.

Best regards,
Filipe Santos.

vsurducan

unread,
May 18, 2022, 10:32:35 PMMay 18
to jal...@googlegroups.com
Cool you find the programmer !
I've seen this issue once too. :) But it was my mistake, I've inverted in a wrong way in the PIC.
thx.


flyway38

unread,
May 19, 2022, 2:59:14 AMMay 19
to jallib
Hi Vasile,

Yes, that progy does the miracle. :D
In my case, only TX needed to be inverted in FTDI configuration.

@Rob,
My mistake (and sorry to Kiste) saying it was Vasile who spoted that OSC misconfigurations first time.
In fact it was Kiste who spoted that mistake and helped me to solve that baud rate issue.

Anyways, thank you all.
This community rocks big time.

Cheers,
Filipe Santos.

Oliver Seitz

unread,
May 19, 2022, 3:06:15 AMMay 19
to jal...@googlegroups.com
;-)

Glad I could help. I know the mistakes, I've made them all by myself. And the one I still don't cope with is confusing names.

Greets,
Kiste

Am Donnerstag, 19. Mai 2022, 08:59:16 MESZ hat flyway38 <fsfo...@gmail.com> Folgendes geschrieben:


flyway38

unread,
May 19, 2022, 3:09:39 AMMay 19
to jallib
Hi Kiste

:D :D .D
Sorry man.
You been of great help here.
Cheers big time.

Best regards,
Filipe Santos.
Reply all
Reply to author
Forward
0 new messages