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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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:
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.
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.
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.
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 :).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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#chip12f1822,8'********************************************************'*GO TO Ser_Init sub To Setup Tx/Rx pins and Baud Rate *'********************************************************dimTxData(4)DimRxData(12)TxData()=10,20,30,40CallSer_InitMain:ForTxValues=1to4bintoasciiTxData(TxValues)Xmit_Print" "NextXmit_RS23213:Xmit_RS23210'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 microForRcvData=1to12CallRcv_RS232'store incoming char Bytes into arrayRxData(RcvData)=RxByteNextdataBytes=0Forsendback=1to4Forsendbytes=1to3dataBytes+=1'echo back received Bytes back to terminalXmit_RS232RxData(dataBytes)NextXmit_Print" "NextXmit_RS23213:Xmit_RS23210gotoMain'************************************************SubSer_Init'for 2400bps delay value'#define baudx 408'#define halfbaudx 204'for 9600bps delay value#definebaudx103'place Read of SerRx in middle of bit#definehalfbaudx52#defineSerTxHighSetPortA.2On#defineSerTxLowSetPortA.2Off#defineSerRxPortA.4dirPortA.2out;TxdirPortA.4in;RxSerTxHigh;InitialRS232idlestateendsubSubRCV_RS232RxWait:'wait for start bitIFSerRxOnThengotoRCV_RS232'do half bit time delaywaithalfbaudxusIfSerRxOnThengotoRxWaitRxByte=0ForRxBit=1to8waitbaudxusRotateRxByteRightIfSerRxOnthenSetRxByte.71IfSerRxOffThenSetRxByte.70NextwaitbaudxusEndsubsubXMIT_PRINT(PrintData$)PrintLen=PrintData(0)ifPrintLen=0thenexitsubforSysPrintTemp=1toPrintLenXMIT_RS232(PrintData(SysPrintTemp))nextendsubSubXMIT_RS232(Xmit_Byte)#NRSerTxLowwaitbaudxusForcntr=1to8RotateXmit_ByteRight#IfDEFPICIfStatus.CONThen#endif#ifdefAVRIfSREG.0OnThen#endifSerTxHighElseSerTxLowEndifwaitbaudxusNextSerTxHighwaitbaudxusendsubsubbintoascii(LCDValue)#NRLCDValueTemp=0LCDShowChar=0SERCEN=0SERDEC=0SERUN=0IfLCDValue>=100thenLCDValueTemp=LCDValue/100LCDValue=SysCalcTempXSERCEN=LCDValueTemp+48Xmit_RS232(SERCEN)LCDShowChar=TRUEEndIfIfLCDShowChar>0orLCDValue>=10thenLCDValueTemp=LCDValue/10LCDValue=SysCalcTempXSERDEC=LCDValueTemp+48Xmit_RS232(SERDEC)EndIfSERUN=LCDValue+48Xmit_RS232(SERUN)EndSubsubbin2ascii(LCDValueasword)#NRDimSysCalcTempXAsWordLCDValueTemp=0LCDShowChar=0SERDECMIL=0SERMIL=0SERCEN=0SERDEC=0SERUN=0IfLCDValue>=10000thenLCDValueTemp=LCDValue/10000[word]LCDValue=SysCalcTempXSERDECMIL=LCDValueTemp+48Xmit_RS232(SERDECMIL)LCDShowChar=TRUEEndIfIfLCDShowChar>0orLCDValue>=1000thenLCDValueTemp=LCDValue/1000[word]LCDValue=SysCalcTempXSERMIL=LCDValueTemp+48Xmit_RS232(SERMIL)LCDShowChar=TRUEEndIfIfLCDShowChar>0orLCDValue>=100thenLCDValueTemp=LCDValue/100[word]LCDValue=SysCalcTempXSERCEN=LCDValueTemp+48Xmit_RS232(SERCEN)LCDShowChar=TRUEEndIfIfLCDShowChar>0orLCDValue>=10thenLCDValueTemp=LCDValue/10[word]LCDValue=SysCalcTempXSERDEC=LCDValueTemp+48Xmit_RS232(SERDEC)EndIfSERUN=LCDValue+48Xmit_RS232(SERUN)EndSub
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
`
Last edit: William Roth 2015-03-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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??
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Last edit: William Roth 2015-03-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
'UseAlternateSoftUARTtosendandreceivedatafromterminal'KentSchafer3/4/2015#chip 12f1822, 8'#configPLLEN=ON#include<SoftSerialX.h>dimTxData(4)DimRxData(12)TxData()=10,20,30,40'************************************************************'SoftSerialX.hcommands*'InitSerX*'SerPrintXbyte,word,string*'SerSendXbyte'fornonasciicharacters*'SerReceiveXbyte*'************************************************************'baudratetable(testedforPICsmayneedadj.forAVRs*'************************************************************'baudrateof9600&19200needs8Mhzclockminimum*'************************************************************'BaudDelayfor19200baudrateis49andHalfBaudis25*'BaudDelayfor9600baudrateis103andHalfBaudis52*'************************************************************'BaudDelayfor9600at4Mhzclockis98andHalfBaudis50*'************************************************************'baudrate2400&4800workwith4MhZandupclock*'BaudDelayfor4800baudrateis206andHalfBaudis103*'BaudDelayfor2400baudrateis408andHalfBaudis204*'************************************************************'Mandatorysyntaxandconstantsforrs232X*'************************************************************'baud19200at8MhZclock#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.1dirPortA.0Out;TxdirPortA.1in;RxCallInitSerX'***********************************************************DimTxWordasWorddimRxData(4)Main:ForTxValues=1to10SerPrintXTxValues'TxData(TxValues)NextSerPrintX"Hi"SerSendX13:SerSendX10ForTxWord=255to1023Step256SerPrintXTxWordwait5msSerSendX13:SerSendX10next'sendcommadelimitedfile(i.e.Bytesfollowedbycomma)'conditional"For ByteCounter = 1 to X"determinesexpectedincomingBytes'TheexampleisexpectingfourBytes'sendfilefromterminal/microexamplefollows'thisform(withoutquotes)like"0,19,133,255,"'programwaitstoreceiveincomingbytesForByteCounter=1to4'ReceivefourcommadelimitedBytesCharCounter=0DoCharCounter+=1CallSerReceiveXRxByteRxData(CharCounter)=RxByte'waitforcommatosignalendofByteIfRxByte=44ThenexitDo'loopbackreceivedcharstoterminalSerSendXRxData(CharCounter)loopSerPrintX" "nextSerSendX13:SerSendX10wait2sgotoMain
Last edit: kent_twt4 2015-03-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
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:
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.
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.
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.
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 :).
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.
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.
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.
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
@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:
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!
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
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
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.
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
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
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.
`
Last edit: William Roth 2015-03-14
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??
@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.
Last edit: William Roth 2015-03-15
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.
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.
Last edit: kent_twt4 2015-03-14
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
@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.]
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.
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.
@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.
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
Please create a new folder for your installation. I would recommend you retain your old structure until you are confident of backwards compatibility.