Help with getting two PIC's talking to each other

[Keith Renecle]

Hi All,
I have a project that requires my LCD display module to read data from the EEPROM in a 16F684, display it on the LCD and then it can be modified and returned to the PIC i.e. the LCD modules becomes a programmer for data into the 684. My display is using the 16F690 as a controller. I have looked through the help stuff but can't seem to find anything that suits my project. Using some previous examples from the forum, I have managed to get the 16F684 to send out data. I can see the pulse train on my scope. It seems that I just can't find a way for the two chips to talk to each other. The two PIC's do not have an UART in them but I thought (??) that I could choose the pins and make one TX and the other Rx and it would work. The other thing is that my 16F684 is running on a 20 MHz crystal while the 690 is running on it's internal clock at 8 MHz. Is that an issue??

I have used GCB for a few years and it's great, but I've never used any serial interface stuff, so I really don't know what I'm doing here. If anyone can point me to a previous thread or can help in any way, I would appreciate it greatly. Thanks.

Oh.......one more thing. The routines for the LCD display in GCB made it so much easier for me to use the LMB 162A display module, so thanks so much to the writers of this amazing program!!

Keith R

[kent_twt4]

Hey Keith, this should work. It is just a matter of setting up who is Master and who is Slave, then how they will talk to each other.

Is it fair to say that the 16f690 LCD module would be the Master and programmer of the 16f684? If that is the case then:

1. Initiate comms by pressing a wakeup/send button on the LCD module. Have the button on a PortA interrupt on change of the 16f690, which is mutually connected to the 16f684. Put soft UART in receive mode.

2. 16f684 receives Port pin change interrupt from the LCD module with it's own Port pin interrupt, reads eeprom and sends data out UART to LCD module. Then, puts itself in UART receive mode.

3. LCD module recieves eeprom data and loads array/register values for further action by buttons to incr/decr. When changes are complete, send values out UART by hitting the wakeup/send button again.

4. 16f684 receives new values in UART, stores them in an array or registers, and sent on to the eeprom after comms complete.

Get the 16f684 and 16f690 sending And receiving out the soft UART to a terminal first, then you will be ready to start experimenting :).

[Keith Renecle]

Hi Kent, thanks for the info. I get the basic idea, but I have not yet played with a soft UART. Are there any examples you can point me to please? What sort of terminal do I need? Thanks.

[kent_twt4]

Here is an example using my Alternate Soft UART routines. Getting Rx frame error using GCBasic soft UART. I use Bray's++ terminal. Good luck.

'Use Alternate Soft UART to send and receive data from terminal
'Kent Schafer 3/4/2015

#chip 12f1822, 8

'********************************************************
'*GO TO Ser_Init sub To Setup Tx/Rx pins and Baud Rate  *
'********************************************************
dim TxData(4)
Dim RxData(12)
TxData() = 10,20,30,40
Call Ser_Init

Main:
For TxValues = 1 to 4
  bintoascii TxData(TxValues)
  Xmit_Print " "
Next
Xmit_RS232 13:Xmit_RS232 10

'wait for info from terminal or micro
'determine how many characters to parse?
'Example is receiving four data Bytes with leading zeros for constant char count
'further parsing required or use different method
'send file from terminal example looks like "015025035045"
'make sure there is delay between Bytes from terminal sending file or micro
For RcvData = 1 to 12
  Call Rcv_RS232
  'store incoming char Bytes into array
  RxData(RcvData) = RxByte
Next
dataBytes = 0
For sendback = 1 to 4
  For sendbytes = 1 to 3
    dataBytes += 1
    'echo back received Bytes back to terminal
    Xmit_RS232 RxData(dataBytes)
  Next
  Xmit_Print " "
Next
Xmit_RS232 13:Xmit_RS232 10
goto Main

'************************************************
Sub Ser_Init
'for 2400bps delay value
'#define baudx 408
'#define halfbaudx 204

'for 9600bps delay value
#define baudx 103
'place Read of SerRx in middle of bit
#define halfbaudx 52
#define SerTxHigh Set PortA.2 On
#define SerTxLow Set PortA.2 Off
#define SerRx PortA.4
dir PortA.2 out ;Tx
dir PortA.4 in ;Rx
SerTxHigh ;Initial RS232 idle state
end sub

Sub RCV_RS232
RxWait:
'wait for start bit
IF SerRx On Then goto RCV_RS232
'do half bit time delay
wait halfbaudx us
If SerRx On Then goto RxWait
RxByte = 0
For RxBit = 1 to 8
  wait baudx us
  Rotate RxByte Right
  If SerRx On then Set RxByte.7 1
  If SerRx Off Then Set RxByte.7 0
Next
wait baudx us
End sub

sub XMIT_PRINT (PrintData$)
PrintLen = PrintData(0)
if PrintLen = 0 then exit sub
for SysPrintTemp = 1 to PrintLen
XMIT_RS232(PrintData(SysPrintTemp))
next
end sub

Sub XMIT_RS232(Xmit_Byte)#NR
SerTxLow
wait baudx us
For cntr = 1 to 8
Rotate Xmit_Byte Right
#IfDEF PIC
If Status.C ON Then
#endif
#ifdef AVR
If SREG.0 On Then
#endif
    SerTxHigh
Else
    SerTxLow
End if
wait baudx us
Next
SerTxHigh
wait baudx us
end sub

sub bintoascii (LCDValue) #NR
LCDValueTemp = 0
LCDShowChar = 0
SERCEN = 0
SERDEC = 0
SERUN = 0

If LCDValue >= 100 then
LCDValueTemp = LCDValue / 100
LCDValue = SysCalcTempX
SERCEN = LCDValueTemp + 48
Xmit_RS232 (SERCEN)
LCDShowChar = TRUE
End If

If LCDShowChar > 0 or LCDValue >= 10 then
LCDValueTemp = LCDValue / 10
LCDValue = SysCalcTempX
SERDEC = LCDValueTemp + 48
Xmit_RS232 (SERDEC)
End If

SERUN = LCDValue + 48
Xmit_RS232 (SERUN)
End Sub

sub bin2ascii (LCDValue as word ) #NR
Dim SysCalcTempX As Word
LCDValueTemp = 0
LCDShowChar = 0
SERDECMIL = 0
SERMIL = 0
SERCEN = 0
SERDEC = 0
SERUN = 0

If LCDValue >= 10000 then
LCDValueTemp = LCDValue / 10000 [word]
LCDValue = SysCalcTempX
SERDECMIL = LCDValueTemp + 48
Xmit_RS232 (SERDECMIL)
LCDShowChar = TRUE
End If

If LCDShowChar > 0 or LCDValue >= 1000 then
LCDValueTemp = LCDValue / 1000 [word]
LCDValue = SysCalcTempX
SERMIL = LCDValueTemp + 48
Xmit_RS232 (SERMIL)
LCDShowChar = TRUE
End If

If LCDShowChar > 0 or LCDValue >= 100 then
LCDValueTemp = LCDValue / 100 [word]
LCDValue = SysCalcTempX
SERCEN = LCDValueTemp + 48
Xmit_RS232 (SERCEN)
LCDShowChar = TRUE
End If

If LCDShowChar > 0 or LCDValue >= 10 then
LCDValueTemp = LCDValue / 10 [word]
LCDValue = SysCalcTempX
SERDEC = LCDValueTemp + 48
Xmit_RS232 (SERDEC)
End If

SERUN = LCDValue + 48
Xmit_RS232 (SERUN)
End Sub

[Keith Renecle]

Hi Kent,
Thanks so much for doing all of that for me, especially all of those extra sub routines. I really appreciate it. I had to do other stuff today unfortunately but I'll get stuck in again in the next day or so. I'll post my results shortly.

[Keith Renecle]

Hi Kent,
I have found out that I can use my PicKit 2 programmer as a UART and terminal, so I've been trying to send and receive with limited results. I do not get what I send always and I've played around with the baud rate and also the wait lengths in the program below. Here is my short program, and I would appreciate it if anyone can tell me what I'm doing wrong here.

chip 16F690, 8

config Osc = Int

define SerInPort PORTA.1

define SerOutPort PORTA.0

define SendAHigh Set SerOutPort off

define SendALow Set SerOutPort on

define RecAHigh SerInPort off

define RecALow SerInPort on

'Set pin directions
Dir SerOutPort Out
Dir SerInPort In

InitSer 1, r300, 1 + WaitForStart, 8, 1, none, invert

Do

wait 200 ms
SerReceive 1, Temp
EPwrite 0, Temp
wait 200 ms
SerSend 1, Temp

Loop

As you can see I also write the received value to EEPROM and sometimes it is what I send from the pc keyboard and other times it's not even close. What am I missing?? Thanks very much.

Keith R

[kent_twt4]

@Keith, "What am I missing?"

Perhaps nothing, have you tried my soft serial routine?

Using the PICKit2 UART tool can be a little awkward when you bounce back and forth from programming the chip. Highly recommend Bray's++ terminal. It can be accessed from GCB_Syn_Write, Terminal menu button, or if not, just download the app. https://sites.google.com/site/terminalbpp/

When entering code in the post use a line feed(space) with 4 tildes and code in between:

Posting
<Space>
(4 tildes here without quotes)
"~~~~"
code here
(4 tildes here without quotes)
"~~~~"
<Space>
Continue Post

[Keith Renecle]

Thanks again Kent, I did look at you program above and I have to admit after looking at it as carefully as I can with my limited programming skills, that I don't have a clue what is going on! This is depressing! I just cannot figure out what all of those subroutines are used for. I just need to read the EEPROM in my 16F684 using the 16F690 in my LCD module. I need to read each 8-bit memory location one at a time, and then add or subtract an amount to it and send it back to the 16F684. Even if I could just echo what I'm typing on my pc keyboard to the 16F690 in my PicKit 2 proto board, that would be a start. My program above does send stuff back and forth but only certain characters come back the same to the screen. If I send 00 for example it comes back as 80 using the HEX setting on the PicKit UART program. I've even tried different baud rates and all.

I had a look at the link to the Bray's terminal but how do I use it? The only link that I have to my pc is via the PicKit 2.

Sorry for these hassles, but it certainly looks like this stuff is way above my head!

[mmotte]

Don't get discouraged! Take it little piece at a time. Your program was in the right direction to making it simple but take out the EEPROM write even to make it simpler. Divide and conquer!

Have you tried the GCbasic online help example for SerPrint. It has all the things you were talking about. It has an input buffer so you could send a line containing a command and data.

If your LCD is the master then you would send a command to get a byte of data. The command would contain: gfor get, address for where i.e. g35. Get the data out of address 35 and send it back

Then when you are done editing the data you would send a : p for put,(data)
OR p35(data) depend on how versatile you want it.

Warning, I have not ever tried this help file routine.

This master-slave command routine is called protocol. One protocol that is used in industry is Modbus. Modbus is used to communicate to PLCs programmable Logic controls that control machines. Usually the PLC is a slave and the Operator interface is the master. So the interface can send data to I/O or memory and it can ask for data from I/O or memory.

Get your comm working first

GL
Mike

[Keith Renecle]

Thanks very much Mike. I am just frustrated and have a bad migraine as well, so this is not a good time to try this out I suppose. I will see if I can find something on SerPrint.

Keith R

[kent_twt4]

Keith, my bad for assuming. I use an USB to ttl serial cable that has the FTDI FT232RL chip. The Prolific PL2303 chip also works well. Just an example of what I'm talking about http://www.ebay.com/itm/6pin-FTDI-FT232RL-USB-to-Serial-adapter-module-USB-TO-TTL-RS232-Arduino-Cable-R3-/181543685138?pt=LH_DefaultDomain_0&hash=item2a44d8cc12
Prolific cables are even cheaper. Hook up the GND and TX and RX (if need be), and you are ready talk to a terminal :). They make the cables with db-9 connector too.

Agreed, my code is a mess, so if I can simplify and use similar syntax to GCB, and wrap it into to a header file I will do so. Also, will post an example when I get there.

[William Roth]

The software serial library was recently updated to improve the TX baud rate accuracy. My testing showed it to be within 2% of nominal at all supported baud rates and clock speeds from 4MHz to 32Mhz. This should not result in any framing errors. With the old library, the baud rates could be off as much as 10% depending upon baud rate and clock speed. If you are not using the updated RS232.h file it can be downloaded here:
https://sourceforge.net/p/gcbasic/code/HEAD/tree/GCBASIC/trunk/include/lowlevel/rs232.h?format=raw.

This not only corrects the baud rate accuracy it also corrected a problem where
"NORMAL" did did not work and sent incorrect correct data due to an inverted start bit. This would cause framing error among other things.

The PIC16F690 DOES have a USART. TX is on RB7 (Pin 10) and RX is on RB5 (Pin 12) so this chip can use hardware serial.

William

[Keith Renecle]

Thanks William, I did download that file and I replaced the one in the "Lowlevel" folder. Was that correct? It still does the same thing on the Pickit 2 UART program. My version of GCB is 0.9 21/8/2012 so do you think that I need to install a newer version. I was a little afraid of doing this because the project that I use this for (model plane timer)works so well. (If it ain't broke.....etc.)

I dug out the 16F690 data sheet and I see now that it does have a USART. My hassle is however, that I'm using that very convenient proto board that comes with the PicKit 2 and the socket is hard wired with pins 18 and 19 going to the I/O socket of the PicKit box. Anyway, thanks again and I'll check all of this out again.......and try not to give up!

Keith R

[William Roth]

Hey Keith,

When troubleshooting a problem simple is better. I happen to have a PIC16F690 already on a breadboard so I programmed it with the code below and checked using the PICKIT2 UART Tool. It works perfectly with no errors. Suggest you try this and verify. Get this working first and then we can move on to RX stuff.

This will work with the latest rs232.H. It will NOT work with the old rs232.h since "Normal" did not work at all with that version.

;**************************************
; Example Code:  Test Software Serial TX
; Author: William Roth 03/13/2015
; File: SoftSerial_Test.gcb
;**************************************

#chip 16F690,8

#define SendAHigh Set PortA.0 ON  
#define SendALow Set PortA.0  OFF
Dir PortA.0 Out

InitSer 1, r9600, 1, 8, 1, none, normal

do
for value = 32 to 127
    SerPrint 1, "Value = "
    serprint 1,value
    sersend 1, 13: sersend 1, 10
    wait 500 ms
next
loop

`

[Keith Renecle]

Hi William,
Thanks so much once again. Wow... you and Kent are a great help! O.K. I tried your short program and I get a screen full of question marks on the PicKit UART program. I considered that it could be the PicKit program it self so I tried it on my older laptop with the original software that comes with it. I soon found that this UART program is not on that version so I updated to the same version as my desktop and it deos exactly the same. On the HEX setting it shows the received hex codes but they are not the same values as your program. It shows:AE B1 B4 BD B5 90 9D 90 9B 99 85 82.

My Pickit version is 2.61.00 I can't see that I have clicked a wrong setting anywhere but of course that is possible. I was getting the same thing with my programs. Any idea's??

[William Roth]

@Keith.

Did you use the exact program I posted with no changes?
Did you set the baud rate in the UART Tool to 9600?
Is your Pickit 2 a genuine Microchip or a clone?

I suggest you update your outdated version of GCB to the latest GCB@Syn version and then replace the rs232.h file with the one from the link I previously posted. Then we can be on the same page, using the same version.

[Keith Renecle]

I do have the original PicKit programmer and a clone, and they both do the same thing. I was out most of today but I'll give this a go tomorrow and do what you suggest and get back to you. Thanks so much so far.

[kent_twt4]

William,
Nice fix, the soft Uart has been a sore spot for a while, which is why I came up with my own version in the first place some time back.

Keith,
Per previous post I have followed up with an alternate SoftSerialX.h header file put up in the contributors section here: https://sourceforge.net/p/gcbasic/discussion/629990/thread/c1313950/#ea68
It can be copied into Notepad, saved as SoftSerialX.h into the GreatCowBasic/include folder (not lowlevel folder!!!)

Here is an example working with that header file that tests all the functions. Use it if you like, or use Williams fix. The transmit function works perfectly fine with PICKit2 UART tool. The receive function of the example has been exasperating with the PICKit2, still not figured out. However, the receive function and echo back to Bray++ terminal, along with an USB to ttl serial cable, works perfectly fine! So I'm signing out on PICKit2 UART tool implementation. Get youself one of those cables, you'll be glad you did.

'Use Alternate Soft UART to send and receive data from terminal
'Kent Schafer 3/4/2015

#chip 12f1822, 8
'#config PLLEN=ON
#include <SoftSerialX.h>
dim TxData(4)
Dim RxData(12)
TxData() = 10,20,30,40
'************************************************************
'SoftSerialX.h commands                                     *
'InitSerX                                                   *
'SerPrintX byte, word, string                               *
'SerSendX byte  'for non ascii characters                   *
'SerReceiveX byte                                           *
'************************************************************
'baudrate table (tested for PICs may need adj. for AVRs     *
'************************************************************
'baudrate of 9600 & 19200 needs 8 Mhz clock minimum         *
'************************************************************
'BaudDelay for 19200 baud rate is 49 and HalfBaud is 25     *
'BaudDelay for 9600 baud rate is 103 and HalfBaud is 52     *
'************************************************************
'BaudDelay for 9600 at 4 Mhz clock is 98 and HalfBaud is 50 *
'************************************************************
'baudrate 2400 & 4800 work with 4 MhZ and up clock          *
'BaudDelay for 4800 baud rate is 206 and HalfBaud is 103    *
'BaudDelay for 2400 baud rate is 408 and HalfBaud is 204    *
'************************************************************
'Mandatory syntax and constants for rs232X                  *
'************************************************************
'baud 19200 at 8 MhZ clock
#define BaudDelay wait 49 us
#define HalfBaudDelay wait 25 us
#define SerTxHigh Set PortA.0 On
#define SerTxLow Set PortA.0 Off
#define SerRx PortA.1
dir PortA.0 Out ;Tx
dir PortA.1 in ;Rx
Call InitSerX
'***********************************************************

Dim TxWord as Word
dim RxData(4)

Main:
For TxValues = 1 to 10
  SerPrintX TxValues                  'TxData(TxValues)
Next
SerPrintX "Hi"
SerSendX 13:SerSendX 10
For TxWord = 255 to 1023 Step 256
    SerPrintX TxWord
    wait 5 ms
    SerSendX 13:SerSendX 10
next

'send comma delimited file (i.e. Bytes followed by comma)
'conditional "For ByteCounter = 1 to X" determines expected incoming Bytes
'The example is expecting four Bytes
'send file from terminal/micro example follows
'this form (without quotes) like "0,19,133,255,"
'program waits to receive incoming bytes
For ByteCounter = 1 to 4      'Receive four comma delimited Bytes
  CharCounter = 0
  Do
    CharCounter += 1
    Call SerReceiveX RxByte
    RxData(CharCounter) = RxByte
    'wait for comma to signal end of Byte
    If RxByte = 44 Then exit Do
    'loop back received chars to terminal
    SerSendX RxData(CharCounter)
  loop
  SerPrintX " "
next
SerSendX 13:SerSendX 10
wait 2 s
goto Main

[William Roth]

Hi Kent,

The goal is to have a standard software serial library that works reliably with both PIC and AVR. I worked on getting the TX baud rates more accurate and Frank fixed the problem with "normal" which was caused by the start and stop bits being inverted. As it is now the PIC TX baud rates of 300 to 19200 are now within 2% of nominal with clock speeds from 4 to 64 MHz. I only had a Mega328p to test at 16Mhz but the rates are good there now as well. More AVRs need to be tested, but I and not really an AVR guy and do not have anything other than the 328P to work with.

I have had to take some personal time lately and have not been able to contribute as much as I would like to. But now I have the time so I will take a further look into rs232.h and see what may need to be done on the RX side of things, if anything.

A basic (optional) software library might be a good idea as the vast majority of apps nowadays only use 8,N,1. But I think the options of using any available I/O pin and the and of inverting the serial data (idle low) should be included.

William

[William Roth]

@Keith

The Pickit 2 also has a simple Logic Tool, so let's use that for debugging this problem. First program the 16F690 with the code below.

1) After Programming, open the Pickit 2 App
2) Select the 16F690 from the list and then open the Logic tool.
3) Select analyzer.
4) Put a check in cursors box.
5) In the triggers area, make Channel 1 = 0. Leave the rest as "*"
6) Sample rate = 1 Mhz. Trigger Position = Start of data.
7) Zoom to 1x
8) Click RUN

You should see a "square" wave on channel 1.
Zoom to 2X and use the slider to position one complete cycle in the display
Left click on first falling edge (red trigger line) to place the X cursor
Right click on the next edge to place the Y cursor.
You should now see the cursor values where X = 0 us and Y = ?

What is the value of Y ?
What is the frequency?

Here is the code: [We send an 85 Decimal / 01010101 binary to produce a "square" wave.]

#chip 16F690,8

#define SendAHigh Set PortA.0 ON
#define SendALow Set PortA.0  OFF
Dir PortA.0 Out

InitSer 1, r9600, 1, 8, 1, none, normal

do
    SerSend 1, 85
    wait 5 ms
loop

[Keith Renecle]

O.K I downloaded the GCB@Syn version and changed the rs232.h file. I managed to get the Synwrite program working and it looks like a good idea. I made the hex file with your receive test program but I still get the ?????????? just like before. I then tried your square wave program and that worked. I'll try to attach a screenshot for you to see the results.

[kent_twt4]

William,
Didn't mean to usurp your work with the soft uart, hadn't realized this was being worked on till your post the previous day or so. Since I had already had the alt soft serial 99% complete, I went ahead and posted it to the contributors section. I hope that know-one thinks of this as any official announcement or internal GCB compiler fix. I've always have used the GCB/include folder (Not lowlevel folder) as a personal playground for large device protocols/procedures.

With all due respect to Hugh, I have never needed three different uart channels. The code was confusing to follow for me, so the simplified version appeared some while back. So I'm all for a simplified version, but I would prefer that is was not included with the official GCB version. I'll look into the invert (idle low), if it's just a matter of initializing the TX pin low? that would be quick and easy.

I am in a similar PIC mostly and a bit of AVR camp. Have a mega168 and some 8 pin Tiny's. For instance, the alt soft serial worked fine with ATTiny13 2400bps at 9.6MHz.

I'm with Keith, on not wanting to change the compiler version (very often) for fear of breaking past code projects. I got caught out by not having archived project hex files. It's heartache when things go wrong. Now using Steini's GCB_Syn_Write, so there's less likelihood that will happen again.

Keith,
The SoftSerialX.h doesn't require a new compiler fix. From my past experience, and heartbreak, it would have been helpful to preserve project hex files. GCB Syn Write will do that, and lot's more!, if you are not using it already.

[William Roth]

@Kent,

I never thought for a moment that you were trying to usurp any official work.

When I first tried software serial about a year ago, it did not work well. 9600 baud produced an actual 10500 baud. "Normal" did not work at all. So, like you, I wrote my own version based upon the then current rs232.h. I only had 8,N,1 38400 baud and "normal" (non inverted) data as this is what I needed for the app I was working on.

Learning from that, I decided to try to improve the official GCB rs232.h as it needed some work. Thus the current rs232.h evolved with help from Frank for fixing the "normal" issue and with input from Hugh and Evan. Attention was paid to backward compatibility. However,now that "normal" works as it is supposed to, any code that worked around the "normal" problem by changing the SendXHigh/SendXLow Ndefines and using invert, will no longer work.

In fact, I think we may need to scour the examples and help file to make they are correct when using normal/true RS232 which is what a PC terminal expects.

I also need to check and test the rs232.h RX code to make sure that the timings are good and that the polarities are correct. So consider the latest rs232.h a serious improvement, but still a work in progress.

[Keith Renecle]

Thanks Kent & William,
I understand some of what you're saying and I must admit that I have not been on the GCB site recently because for my simple projects for use on mostly my model planes, I was totally happy with the last version of GCB ver.0.9 21/8/2012. I use Crimson Editor and just drag the saved hex file over the Compilier icon and then load the compiled filed into the PicKit 2.

I have downloaded the GCB@Syn zipped files now, so do I need to uninstall the old GC Basic program and remove all of the folders or what? I'm hoping that then I can still use this with my older stuff. Thanks.

Keith R

[Anobium]

Please create a new folder for your installation. I would recommend you retain your old structure until you are confident of backwards compatibility.