Keith, I have copied my CrimsonEditor program files folder into the SynWrite/myfiles folder. Pull up files from the Crimson folder all the time as a template, work on them, and save them to a new (going forward) myfiles subfolder.
Agree with William to keep the old GCB compiler and Crimson Editor program files archived, and separate from GCBSYNWrite.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to the logic tool, each bit is 186/2 or 93 us. That means the actual baud rate is 10,752. This is way too high for 9600 and is about what I measured with the OLD rs232.h. I suspect that the wrong rs232.h file is installed in the new gcb@syn/greatcowbasic/include/lowlevel folder.
Please open the rs232.h file and check the copyright date on line 2. It should read:
Copyright (C) 2006, 2014, 2015 Hugh Considine, Evan R Venn, William Roth
In the script a few lines below you will find the SerialFullDelay timings. They should read:
Looks like my 690 is the culprit. I checked the file and it is as you copied above. I then wrote a short program to send out a pulse with 1 ms ON and 1 ms OFF. It was running faster on my scope, so I tried the same thing on another spare PIC, the 12F683 that I had on my workbench, and the pulse width was spot on. I then tried your soft serial test on the 683 and it worked properly. Whoopeeeeee!
After this I tried your square wave test and as you can see from the attached pic, it looks a lot better. O.K. so thanks for that. I'll see if I can add a 20 MHz crystal to the 690 and try it again. So now will you please send the Rx program? Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is a code snippet to test the 16F690. Load the program then measure the frequency at Pin 3 (clock out) and at Pin 10.
The frequency at Pin 3 should be 2Mhz and at Pin 10 should be approximately 500 hz.
If the frequency at Pin 3 is NOT 2Mhz then it is possible that the factory calibration WORD got inadvertently erased or changed. If the factory Calibration WORD is corrupted or erased, it is probably best to just bin the chip and get a new one. There are ways to reprogram it, but Microchip has made it difficult.
This all assumes that the 690 is programed with the EXACT code below and there is nothing connected to the PIC that could be causing problems. Also assuming a 10K pullup resistor from MCLRE (Pin 4) to Vdd.
Let me know what frequency you measure at Pin 3.
William
; FILE: Test_Freq_PIC16F690
; DATE: 17.03.15
; VERSION: N/A
; AUTHOR: William Roth
; Description.
' This code tests the internal RC Clock speed of a PIC16F690
;
; Read Frequency at Pin 3 with scope. (Expecting 2Mhz)
; Read Frequency at Pin 10 with scope. (Expecting 497 Hz)
;
; ----- Configuration
#chip 16f690, 8
#config INTRC_OSC_CLKOUT ' clock out on Pin 3. (2Mhz Expected)
IRCF0 = 1 'OSCCON Bit 0
IRCF1 = 1 'OSCCON Bit 1
IRCF2 = 1 'OSCCON Bit 2
#Define PIN_10 PortB.7
Dir PIN_10 Out ' Pin 10
Do
Set PIN_10 ON
Wait 1 ms
Set Pin_10 off
Wait 1 ms
LOOP
END
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as the RX side of software serial goes, I will be working on that this week. But remember, the 16F690 also supports hardware serial. Your other chip does not.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried the suspect 690 chip with a 20 MHz crystal and it also worked on your test program with the uart on the PicKit 2. Today I went out and bought a few more of the 690's and they work fine without the crystal, so I guess that the original chip has a timing error. I must thank you guys out there for the help. I was really at the point of giving up!
Now I'm playing with trying to get the 690 on my LCD module to talk to my other PIC's EEPROM.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So far my very limited testing shows that software serial receive will work OK up to 4800 baud using a Pic16F690 @ 8Mhz. Receiving at 9600 failed, but it "may" work at 9600 baud if the processor speed is >= 16MHz. I tested by sending bytes at "exactly" 2400,4800 and 9600 baud using "normal" polarity. 19200 baud was not tested.
More extensive testing with various PICs at clock speeds from 4 Mhz to 64 Mhz will be done this week. If necessary, rs232.h RX timings will be adjusted for optimal performance.
RX receive rates are limited by MCU clock speed and the related processing overhead.
The higher the MCU speed the higher the RX Baud rate can be.
I will make a chart of what RX baud rates will work according to MCU Speed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using an 8-Channel Salea Logic Analyzer, with the Async Serial Analyzer plug-in, as well as a TEK THS730A Scope.
The Pickit 2 is nice for rough measurements, but with a max sample rate of 1Mhz, it does not have the resolution/accuracy that I want. However, it should be perfectly fine for verification by users.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Update: By adjusting the RX timing in rs232.h, software serial receive will work at 9600 baud with an 8 MHz MCU Clock.
This is encouraging, but it also means that I will have to check/modify all timings so that RX will reliably receive data at all implemented baud rates with a tolerance goal of +- 4%.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Guys, I have now managed to get my 690 working with the LCD and my other gadget with the 16f684 processor. I've been able to send data to the 684 and echo it back. I'm still busking my way through all this but it's starting to make a little sense to me right now. I don't need high speed and it works even at 400 baud.
Thanks to you guys that helped me so much to understand what's cooking. I really appreciate it. I never cease to be amazed at how much you can achieve with GC Basic with so little programming knowledge!
Keith R
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Anobium, I did that and have both systems working now. Good tip!
Keith, I have copied my CrimsonEditor program files folder into the SynWrite/myfiles folder. Pull up files from the Crimson folder all the time as a template, work on them, and save them to a new (going forward) myfiles subfolder.
Agree with William to keep the old GCB compiler and Crimson Editor program files archived, and separate from GCBSYNWrite.
@keith,
According to the logic tool, each bit is 186/2 or 93 us. That means the actual baud rate is 10,752. This is way too high for 9600 and is about what I measured with the OLD rs232.h. I suspect that the wrong rs232.h file is installed in the new gcb@syn/greatcowbasic/include/lowlevel folder.
Please open the rs232.h file and check the copyright date on line 2. It should read:
Copyright (C) 2006, 2014, 2015 Hugh Considine, Evan R Venn, William Roth
In the script a few lines below you will find the SerialFullDelay timings. They should read:
If either of these do not match your Rs232.h then it is the wrong file.
It is either the wrong rs232.h file or the 16F690 is operating at something other than 8 MHz.
Hi William,
Looks like my 690 is the culprit. I checked the file and it is as you copied above. I then wrote a short program to send out a pulse with 1 ms ON and 1 ms OFF. It was running faster on my scope, so I tried the same thing on another spare PIC, the 12F683 that I had on my workbench, and the pulse width was spot on. I then tried your soft serial test on the 683 and it worked properly. Whoopeeeeee!
After this I tried your square wave test and as you can see from the attached pic, it looks a lot better. O.K. so thanks for that. I'll see if I can add a 20 MHz crystal to the 690 and try it again. So now will you please send the Rx program? Thanks
O.K. I missed the attachment. Here it is!
@Keith
Here is a code snippet to test the 16F690. Load the program then measure the frequency at Pin 3 (clock out) and at Pin 10.
The frequency at Pin 3 should be 2Mhz and at Pin 10 should be approximately 500 hz.
If the frequency at Pin 3 is NOT 2Mhz then it is possible that the factory calibration WORD got inadvertently erased or changed. If the factory Calibration WORD is corrupted or erased, it is probably best to just bin the chip and get a new one. There are ways to reprogram it, but Microchip has made it difficult.
This all assumes that the 690 is programed with the EXACT code below and there is nothing connected to the PIC that could be causing problems. Also assuming a 10K pullup resistor from MCLRE (Pin 4) to Vdd.
Let me know what frequency you measure at Pin 3.
William
@keith
As far as the RX side of software serial goes, I will be working on that this week. But remember, the 16F690 also supports hardware serial. Your other chip does not.
I tried the suspect 690 chip with a 20 MHz crystal and it also worked on your test program with the uart on the PicKit 2. Today I went out and bought a few more of the 690's and they work fine without the crystal, so I guess that the original chip has a timing error. I must thank you guys out there for the help. I was really at the point of giving up!
Now I'm playing with trying to get the 690 on my LCD module to talk to my other PIC's EEPROM.
So far my very limited testing shows that software serial receive will work OK up to 4800 baud using a Pic16F690 @ 8Mhz. Receiving at 9600 failed, but it "may" work at 9600 baud if the processor speed is >= 16MHz. I tested by sending bytes at "exactly" 2400,4800 and 9600 baud using "normal" polarity. 19200 baud was not tested.
More extensive testing with various PICs at clock speeds from 4 Mhz to 64 Mhz will be done this week. If necessary, rs232.h RX timings will be adjusted for optimal performance.
RX receive rates are limited by MCU clock speed and the related processing overhead.
The higher the MCU speed the higher the RX Baud rate can be.
I will make a chart of what RX baud rates will work according to MCU Speed.
@William,
Which debug method?; dedicated terminal app, or PicKit2 uart tool.
@Kent,
I am using an 8-Channel Salea Logic Analyzer, with the Async Serial Analyzer plug-in, as well as a TEK THS730A Scope.
The Pickit 2 is nice for rough measurements, but with a max sample rate of 1Mhz, it does not have the resolution/accuracy that I want. However, it should be perfectly fine for verification by users.
@William
Wow..OK, I now know who to go to for accurate measurements!, thanks.
Update: By adjusting the RX timing in rs232.h, software serial receive will work at 9600 baud with an 8 MHz MCU Clock.
This is encouraging, but it also means that I will have to check/modify all timings so that RX will reliably receive data at all implemented baud rates with a tolerance goal of +- 4%.
Hi Guys, I have now managed to get my 690 working with the LCD and my other gadget with the 16f684 processor. I've been able to send data to the 684 and echo it back. I'm still busking my way through all this but it's starting to make a little sense to me right now. I don't need high speed and it works even at 400 baud.
Thanks to you guys that helped me so much to understand what's cooking. I really appreciate it. I never cease to be amazed at how much you can achieve with GC Basic with so little programming knowledge!
Keith R