Just wanna say, I LOVE GCB ! and in a perfect world everything works the first time...Alaaaassss......
Having issues with serial communication between two PIC chips and after looking under the hood, it looks like it may have something to do with the baud rate declaration in the chip file for the PIC18F67J50.
Using the latest GCB install v.0.97.01.00 (Had the same issue with the previous version of GCB, same chip file ?)
USART TX1 from PIC18F67J50 running at 48MHz (external crystal osc)
USART RX into PIC12F1840 running at 32MHZ (internal osc)
both chips #define USART_BAUD_RATE 9600
VERIFIED both chips correctly running at their respective speed using timers to measure clock speed.
sending integer "zero" (or any byte for that matter) from PIC18F67J50 measures 3.78ms on our logic analyzer...at 9600 baud that should be around 1ms.
changing baud rate on PIC18F67J50 to #define USART_BAUD_RATE 38400 suddenlymakes everything work perfectly. Exactly 4X faster than the baud rate of 9600.
As a quick fix (until the next revision of this chip file) what can we change in the chip file assembly code to correct this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For some reason the baudrate generator is not calculating properly? I have not looked at the underlying hardware usaurt library!
Looking at the assembly, the baudrate formula divisor appears to be already set at the lowest value of FOSC/((4*(n+1). So here is an untested work around?
It lets gcb set up the INITUSART as it normally would
Then applies a 4X factor to the baudrate formula by Call to INITUSART_X to reformulate SPBRG registers ( i.e. FOSC/(1*(n+1)) ).
'Chip model
#chip 18F67j50,48
#config FOSC=HS
#define USART_BAUD_RATE 9600
#define USART_BAUD_RATE_X 9600
call initusart_x
test = 99
HSerPrint test
sub INITUSART_X
#script
BaudrateTemp = int((chipmhz*1000000/USART_BAUD_RATE_X) - 1)
BaudHigh = int(BaudrateTemp/256)
BaudLow = int(BaudrateTemp - (BaudHigh*256))
#endscript
;comport = 1; movlw 1; movwf COMPORT,BANKED;SPBRG1 = SPBRGL_TEMP
SPBRGL = BaudLow
' movlw 135 => this is hand calc'd value
' movwf SPBRG1,ACCESS
;SPBRGH1 = SPBRGH_TEMP
SPBRGH = BaudHigh
' movlw 19 => this is hand calc'd value
' movwf SPBRGH1,ACCESS
;BAUDCON1.BRG16 = BRG16_TEMP
' bsf BAUDCON1,BRG16,ACCESS
';TXSTA1.BRGH = BRGH_TEMP
' bcf TXSTA1,BRGH,ACCESS
';Set SYNC1 Off
' bcf TXSTA1,SYNC1,ACCESS
';Set SPEN1 On
' bsf RCSTA1,SPEN1,ACCESS
';Set CREN1 On
' bsf RCSTA1,CREN1,ACCESS
';Set TXEN1 On
' bsf TXSTA1,TXEN1,ACCESS
end sub
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have looked at the library and I can see obvious error.
So, test this please. Set the chip to the internal 8mhz frequency and retest. I am thinking there is something wrong with the config - so, by testing with the internal oscillator we can prove/or disprove the libirary is ok.
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks everyone for the help...what a great community !
OK, tried the test...
For the PIC18F67J50...
- Set the OSC to internal 8MHz
- declared #define USART_BAUD_RATE 9600
- measured the time for a single byte transmitted out of the USART TX pin = 2.48 ms
- this would imply a baud rate of 4800...and no it did not work, since the PIC12F1840 RX is expecting a baud rate of 9600.
- changed the PIC12F1840 to #define USART_BAUD_RATE 4800, RX still did not work.
The oscillator setup for the 18F67J50 is complex considering it must accomodate 8 different oscillator modes to accomodate built in USB functionality
Is the problem in the chip library ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
More information could possibly help, like the minimum code and config setup that is being used (see above example). Is the 48Mhz crystal directly attached to OSC1 and OSC2? as opposed to being borrowed from another source.
Usually speeds like 48Mhz and above are derived by using much lower frequency crystals and then using a PLL multiplier and PLL divider. That chip seems to be all for using a 25Mhz crystal for the ethernet module.
Did you try the InitUsart_X example, for giggles?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
BB,
I looked for the problem today for a couple hours, Building little test programs and looking for differences in the listing ( .lst file). I do not have a 18F67J50 but some other 18F chips and have only tested them with the internal osc.
Two questions:
1) Please send the #chip and #config lines of your .gcb file.
Something like :
<
chip 18f67J50, 48
config OSC = EC
/>
The .dat file for 18F67J50 says these are your options.
FOSC=INTOSC,INTOSCO,INTOSCPLL,INTOSCPLLO,HS,HSPLL,EC,ECPLL
I am not sure if you are running and external xtal osc(EC) or external crystal (HS)?
PLL?
Thanks again for all the help, what a great resource in this forum! After viewing the compiled .lst file, it is evident that the GCB baud rate calculator is generating incorrect values for SPBRGH and SPBRG (as kent_twt4 had suggested above).
According to the data sheet for the PIC18F67J50 with FOSC = 48mHz and SYNC, BRG16, BRG = 0, the baud rate can be calculated with the formula
Plugging these values directly into my code works perfectly and both chips are now able to pass data to each other.
However, using #define USART_BAUD_RATE 9600...
SYNC, BRG16, BRG = 0
SPBRGH = 4
SPBRG = 225
Which is incorrect for baud 9600. I have a notion there are other GCB chipset files for the PIC18F family that are generating the same bad math, possibly something worth looking into and fixing at some point. Until then as a work around, declare values for SPBRH and SPBRG in your code AFTER the call to INITUSART and use #define USART_BAUD_RATE to set up the other USART registers.
Fortunately, using #define USART_BAUD_RATE 9600 with a PIC12F1840 works perfectly.
BB
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am looking at resolving the initial question to resolve any potential issue in the library. I have looked into this for many hours. I can see nothing incorrect. The calcuation code had not been changed since the initial implementation.
As shown by your posting. Using the calculation of = ((48000000/9600)/64) – 1 does yield the correct result when you are using on the PIC18F67J50 but this is an 8-bit calculation where SYNC=0, BRG16=0 and BRGH=0.
Great Cow BASIC uses 16-bit calculation where SYNC=0, BRG16=1 and BRGH= 0 or 1 dependent baud rate or frequency. This is shown in the TABLE 20-1: BAUD RATE FORMULAS of the datasheet.
I have validated the code we have in the library and that looks correct for 16-bit calcutions.
This should work based upon the library for 48mhz, 9600 bps
SYNC=0'always 0BRG16=1' always 1BRG=1' 1 for the calculated values shown below. SPBRGH = 4 SPBRG = 225
So, I need to see you acutal source code. Are you setting baud rate registers outside the source code? or, is the chip simply running at a frequency that you are not expecting?
Really puzzled here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Notice on the 6th line down, my code BSF's BRGH in TX1STA, BANKED and your code BSF's BRGH in TXSTA1, ACCESS. Scouring the data sheet, there is no such register with the name TX1STA but TXSTA1 is valid. Could this be the source of the error, since BRGH never actually gets set? Wouldn't the compiler cry foul if it encountered such a non-existant register? I see reference on the internet to TX1STA and RC1STA, did Microchip change the name of the register at some point ?
Also, since the PIC18F67J50 is endowed with 2 USART harware modules, distinguished by TXSTA1, TXSTA2, RCSTA1, and RCSTA2, I'm confused as to how the code above in both cases refers to TXSTA and RCSTA without reference as to which register to address?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here's the complete main source code (I did not include the .h files, that would be a lot and likely don't apply to this issue...you'll see them in assembled code following anyway)
Schoolboy error by me. I should have checked earlier. What version of the compliler and IDE release? I think you are on GCBASIC 0.94 2015-04-02 according to the LST file.
Please test with the latest release. We did fix a TX1STA mapping issue about 18 months ago, so, you issue should be fixed in the latest release.
Edited: Please install the latest release. Test and then post all the resutling files as a ZIP.
Last edit: Anobium 2017-08-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Issue SOLVED ! I did upgrade and install v0.97 back in April but I am embarrassed to say I have been inadvertantly still opening up an older version v.95 all this time but didn't know it. I should have just uninstalled everything related to the older version before installing v.97. Talk about schoolboy error...this one is on me ! Truly one of those palm to forehead moments. Pardon my French...what a dumbass am I....
Everything works perfectly now using the GCB USART declarations. Thanks for your persistence and help, though completely a waste of time for you and others. My apologies. Keep up the fine work, regardless !
BB
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just wanna say, I LOVE GCB ! and in a perfect world everything works the first time...Alaaaassss......
Having issues with serial communication between two PIC chips and after looking under the hood, it looks like it may have something to do with the baud rate declaration in the chip file for the PIC18F67J50.
As a quick fix (until the next revision of this chip file) what can we change in the chip file assembly code to correct this?
Thanks for the feedback - this is community effort and your comments are very welcome.
For some reason the baudrate generator is not calculating properly? I have not looked at the underlying hardware usaurt library!
Looking at the assembly, the baudrate formula divisor appears to be already set at the lowest value of FOSC/((4*(n+1). So here is an untested work around?
I have looked at the library and I can see obvious error.
So, test this please. Set the chip to the internal 8mhz frequency and retest. I am thinking there is something wrong with the config - so, by testing with the internal oscillator we can prove/or disprove the libirary is ok.
Thank you.
Thanks everyone for the help...what a great community !
OK, tried the test...
For the PIC18F67J50...
- Set the OSC to internal 8MHz
- declared #define USART_BAUD_RATE 9600
- measured the time for a single byte transmitted out of the USART TX pin = 2.48 ms
- this would imply a baud rate of 4800...and no it did not work, since the PIC12F1840 RX is expecting a baud rate of 9600.
- changed the PIC12F1840 to #define USART_BAUD_RATE 4800, RX still did not work.
The oscillator setup for the 18F67J50 is complex considering it must accomodate 8 different oscillator modes to accomodate built in USB functionality
Is the problem in the chip library ?
More information could possibly help, like the minimum code and config setup that is being used (see above example). Is the 48Mhz crystal directly attached to OSC1 and OSC2? as opposed to being borrowed from another source.
Usually speeds like 48Mhz and above are derived by using much lower frequency crystals and then using a PLL multiplier and PLL divider. That chip seems to be all for using a 25Mhz crystal for the ethernet module.
Did you try the InitUsart_X example, for giggles?
BB,
I looked for the problem today for a couple hours, Building little test programs and looking for differences in the listing ( .lst file). I do not have a 18F67J50 but some other 18F chips and have only tested them with the internal osc.
Two questions:
1) Please send the #chip and #config lines of your .gcb file.
Something like :
<
chip 18f67J50, 48
config OSC = EC
/>
The .dat file for 18F67J50 says these are your options.
FOSC=INTOSC,INTOSCO,INTOSCPLL,INTOSCPLLO,HS,HSPLL,EC,ECPLL
I am not sure if you are running and external xtal osc(EC) or external crystal (HS)?
PLL?
00011A 0EE1 MOVLW 225
00011C 6EB0 MOVWF SPBRG1,ACCESS
00011E 0E04 MOVLW 4
000120 6E7F MOVWF SPBRGH1,ACCESS
000122 867E BSF BAUDCON1,BRG16,ACCESS
000124 84AD BSF TXSTA1,BRGH,ACCESS
000126 98AD BCF TXSTA,SYNC1,ACCESS
000128 8EAC BSF RCSTA,SPEN1,ACCESS
00012A 88AC BSF RCSTA,CREN1,ACCESS
00012C 8AAD BSF TXSTA,TXEN1,ACCESS
00012E 0012 RETURN
/>
I looked at the chip dat file and it has all the registers that are needed plus some aliases.
BR
M
Thanks again for all the help, what a great resource in this forum! After viewing the compiled .lst file, it is evident that the GCB baud rate calculator is generating incorrect values for SPBRGH and SPBRG (as kent_twt4 had suggested above).
According to the data sheet for the PIC18F67J50 with FOSC = 48mHz and SYNC, BRG16, BRG = 0, the baud rate can be calculated with the formula
FOSC/[64 (n + 1)]
Solving for n = Desired Baud Rate
n = ((FOSC/Desired Baud Rate)/64) – 1
= ((48000000/9600)/64) – 1
= [77.125] = 77
Calculated Baud Rate = 48000000/(64 (77 + 1)) = 9615
Error = (Calculated Baud Rate – Desired Baud Rate)/Desired Baud Rate = (9615 – 9600)/9600 = 0.16% (Not Bad)
Thus...
SPBRGH = 0
SPBRG = 77
Plugging these values directly into my code works perfectly and both chips are now able to pass data to each other.
However, using #define USART_BAUD_RATE 9600...
SYNC, BRG16, BRG = 0
SPBRGH = 4
SPBRG = 225
Which is incorrect for baud 9600. I have a notion there are other GCB chipset files for the PIC18F family that are generating the same bad math, possibly something worth looking into and fixing at some point. Until then as a work around, declare values for SPBRH and SPBRG in your code AFTER the call to INITUSART and use #define USART_BAUD_RATE to set up the other USART registers.
Fortunately, using #define USART_BAUD_RATE 9600 with a PIC12F1840 works perfectly.
BB
Great news.
Can you confirm that the code posted early in this dicussion is representive of code with the calculation issu?
This code reproduces the issue.
What is the similar code for the 12F1840 that works? frequency and config are the key pieces of information I am missing.
@Blaise Barton.
I am looking at resolving the initial question to resolve any potential issue in the library. I have looked into this for many hours. I can see nothing incorrect. The calcuation code had not been changed since the initial implementation.
As shown by your posting. Using the calculation of
= ((48000000/9600)/64) – 1does yield the correct result when you are using on the PIC18F67J50 but this is an 8-bit calculation where SYNC=0, BRG16=0 and BRGH=0.Great Cow BASIC uses 16-bit calculation where SYNC=0, BRG16=1 and BRGH= 0 or 1 dependent baud rate or frequency. This is shown in the TABLE 20-1: BAUD RATE FORMULAS of the datasheet.
I have validated the code we have in the library and that looks correct for 16-bit calcutions.
This should work based upon the library for 48mhz, 9600 bps
Also see: http://www.nicksoft.info/el/calc/?ac=spbrg&submitted=1&mcu=+Generic+16bit+BRG&Fosc=48&FoscMul=1000000&FoscAutoSelector=0&MaxBaudRateError=1
So, I need to see you acutal source code. Are you setting baud rate registers outside the source code? or, is the chip simply running at a frequency that you are not expecting?
Really puzzled here.
@Anobium
On my end, these declarations in GCB produce the assembly code in the .lst file below and doesn't exactly match the code you had posted previously:
Here's the resultant snippet in the .lst file
0017F4 0EE1 MOVLW 225
0017F6 6EB0 MOVWF SPBRG1,ACCESS
0017F8 0E04 MOVLW 4
0017FA 6E7F MOVWF SPBRGH1,ACCESS
0017FC 867E BSF BAUDCON1,BRG16,ACCESS
0017FE 855D BSF TX1STA,BRGH,BANKED
001800 98AD BCF TXSTA,SYNC1,ACCESS
001802 8EAC BSF RCSTA,SPEN1,ACCESS
001804 88AC BSF RCSTA,CREN1,ACCESS
001806 8AAD BSF TXSTA,TXEN1,ACCESS
001808 0012 RETURN
Now here's the code you generated:
00011A 0EE1 MOVLW 225
00011C 6EB0 MOVWF SPBRG1,ACCESS
00011E 0E04 MOVLW 4
000120 6E7F MOVWF SPBRGH1,ACCESS
000122 867E BSF BAUDCON1,BRG16,ACCESS
000124 84AD BSF TXSTA1,BRGH,ACCESS
000126 98AD BCF TXSTA,SYNC1,ACCESS
000128 8EAC BSF RCSTA,SPEN1,ACCESS
00012A 88AC BSF RCSTA,CREN1,ACCESS
00012C 8AAD BSF TXSTA,TXEN1,ACCESS
00012E 0012 RETURN
Notice on the 6th line down, my code BSF's BRGH in TX1STA, BANKED and your code BSF's BRGH in TXSTA1, ACCESS. Scouring the data sheet, there is no such register with the name TX1STA but TXSTA1 is valid. Could this be the source of the error, since BRGH never actually gets set? Wouldn't the compiler cry foul if it encountered such a non-existant register? I see reference on the internet to TX1STA and RC1STA, did Microchip change the name of the register at some point ?
Also, since the PIC18F67J50 is endowed with 2 USART harware modules, distinguished by TXSTA1, TXSTA2, RCSTA1, and RCSTA2, I'm confused as to how the code above in both cases refers to TXSTA and RCSTA without reference as to which register to address?
TX1STA was defined as result of an issue in the early release of Great Cow BASIC hence it would not be found as a valid address.
The current build of the Great Cow BASIC take greater care of ensuring the registers and register.bits are defined in the chip.dat file.
See my post below to get you onto the latest release so we can sort this out.
Can you please post your actual source code and all the generated asm files.
I need to review everything.
Forgot to include in the above GCB declarations for the PIC18F67J50:
And the code for the 12F1840...
Last edit: Anobium 2017-08-01
@Anobium
Here's the complete main source code (I did not include the .h files, that would be a lot and likely don't apply to this issue...you'll see them in assembled code following anyway)
Last edit: Anobium 2017-08-01
@Amobium
Here's the resultant assembly file...
Last edit: Anobium 2017-08-01
Schoolboy error by me. I should have checked earlier. What version of the compliler and IDE release? I think you are on GCBASIC 0.94 2015-04-02 according to the LST file.
Please test with the latest release. We did fix a TX1STA mapping issue about 18 months ago, so, you issue should be fixed in the latest release.
Edited: Please install the latest release. Test and then post all the resutling files as a ZIP.
Last edit: Anobium 2017-08-01
Issue SOLVED ! I did upgrade and install v0.97 back in April but I am embarrassed to say I have been inadvertantly still opening up an older version v.95 all this time but didn't know it. I should have just uninstalled everything related to the older version before installing v.97. Talk about schoolboy error...this one is on me ! Truly one of those palm to forehead moments. Pardon my French...what a dumbass am I....
Everything works perfectly now using the GCB USART declarations. Thanks for your persistence and help, though completely a waste of time for you and others. My apologies. Keep up the fine work, regardless !
BB
Pleasure. I wrote a white pape explaining how the baud rate calculator works so I am happy.
Pleasure