It would be really good if GCB will be set the default config to OSC = INTIO67. GCB is not setting the INTOSC in config at all for the 18fxxk20 or 18fxxk22 families, although 16mhz intosc works because that is the POR default. Other families may or may not be affected.
If one can remember? the workaround is to set the config manually with #config OSC = INTIO67. There is no other problem to my knowledge, as the OSCCON and OSCTUNE (if the PLL is being used) registers are being set correctly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Kent. I only use 18f25k22 for pic use..I like it and have a few.
I have had no problems that I know using it at 16 or 64. I'm missing the point. Should I have been setting osc all the while? You have confused me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey Stan, here is a simple test case. No output to the Terminal. No INTOSC in config output.
This compiled from v98 RC05, but I have same problem with other versions too.
What GCB version, and what is your asm output for the test program (with "no" #config operations)? Does this program work with a Terminal in your version?
'Chip model, Oscillator frequency FOSC
#chip 18f46k22,64
'#config OSC=INTIO67
#define Usart_Baud_Rate 9600
#define Usart_Blocking
dir PortC.6 Out
Main:
HSerPrint "hello"
HSerPrintCRLF
wait 1 s
goto Main
We may also need to check the ASM INITSYS routine to make sure the PLL and OSCCON bits are properly set. But I suspect they will be.
Attached is a list of all PIC 18F Devices currently in production that support a 64MHz Clock. The datfiles for these chips will all need to be checked and corrected as necessary.
Brilliant! I had looked at the chipdata file straight on and it did not even register to me that the missing Intosc settings were missing, good catch. Ha, I had thought this might have been a compiler problem.
Changed the 18f46k22 and 18k26k20 .dat files IntOsc= settings for 64, and 32, and all is well. Confirmed the config INTIO67 shows up now. For 32 and 64 mhz settings the INITSYS sub OSCCON bits and PLLEN bit of OSCTUNE set correctly. And, the hardware usart timing is now functioning properly for both settings.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Take the PIC18F26K22. PIC18F26K22 according MAPS (the tool from Microchip) the max int osc is 32. This is data with an Excel spreadsheet. PIC18F26K22 according the datasheet the max int osc is 64 with PLL.
Let us not debate the use of PLL etc. I need a reliable data source so we can make the correct setting in the chip database. I just need to know how to figure out whether to set the chip database to 64 - and, I am not willing to wade through 63 datasheets.
Take the 18F46K22.
The datasheet is more hopeful as this states 64 with PPL for the following 18 chips.
Summary, I just need a list of which chips should be set to Int Osc = 64.
:-)
So, I just just updated the chip database based upon this single datasheet. I have updated the datasource provided by Bill. The task is simple - what others?
Backchecked the hardware serial for the 18f26k20 and the 18f26k22.
For the 18f26k20 the INITSYS is not setting the OSCCON bits properly for "sub <16 chipmhz settings". For instance, with chipmhz of 8 the asm, OSCCON set to 112 which is the for 16mhz. Same type of problem for 4mhz, 1mhz. The HSerPrint baud rate suggests OSCCON OSC frequency settings are 2x what it should be:
'this is the asm for chipmhz of 8
INITSYS
;nop ' This is the routine for the OSCCON config
nop
;OSCCON = OSCCON OR b'01110000'
movlw 112
iorwf OSCCON,F,ACCESS
For 18f46k22 the hardware serial is good across tested range of chipmhz of 1,4,8,16,32,64.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Kent. Please update the datasource (18f_64MHz Rev1.txt) else this will come off the rails and I will be totally confused. Change the revision number so I can track, and, attach to your posting.
And, can we resolve the .dat issue first - let fix the other issue later.
Last edit: Anobium 2017-09-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sourceforge is giving a 404 error for 18f_64MHZ Rev1.txt. I did however still have the original list from William still on the desktop.
So here is the progress to date on verifying 64mhz capability thru datasheets, and whether the GCB .dat sheet has correctly implemented IntOsc= 64,32,... some of them are OK by the looks of them.
OK, here is the last of the original list. No judgement is being made on PLL or DIV bits etc. I think the source files can be counted on to setting the MaxMHZ=64 correctly, and perhaps that how the list originated?
So, I will update the chip database to the information in the file? This is a Y or N answ
The answer is NO.
Attached is new list with suggested additions to dat files "IntOsc =".
Pertaining to the 18f97J94 Family I have no suggestions due to the myriad of possibilities with USB devices.
Let me know if more info or help is needed. For instance if it just changing the .dat files, I could do that and zip them to you. If it is changing how you parse mchp .inc files or something else then no help.
We do not want to change the .dat files manually. I will regen the .dat files after we have corrected the chip database otherwise we will loose the changes in the future.
By changing the chip datase the 'IntOsc =' will be updated when I regen the all the chip .dat files. We have a number of other 'injectors' into the regen software to make forced changed to the Microchip INC files - the 'injectors' are the documented changes we need to change to resolve errors, mistakes and omissions within the Microchip INC files.
So, to update the "IntOsc =" I need to update the chip database to maintain consistency and quality of the dat file.
Makes sense?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The NO becomes a YES with the "suggested additions to IntOsc=" in the 18F_64MHZ_REV1C.txt. As already noted by adding IntOsc = 64, 32 to the existing 18f46k22.dat file, produces the desired effect of allowing higher INTOSC speeds by default, now allows the CONFIG to be set to FOSC = INTIO67, and INITSYS OSCCON and PLL bits were being set properly.
Whether similar PIC K80 and K90 families will behave in a like manner way? There seems to be hope that they will. I manually added IntOsc= 64 to the 18f46k80.dat file and then compiled the hardware serial test case program. FOSC = INTIO2 is being set in CONFIG, and the INITSYS IRCF and PLLEN enable bits look good. Same for adding IntOsc = 64, 32 to the 18f65k90.dat file. Don't have examples of these devices to physically test.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This has been touched before in previous posts.
It would be really good if GCB will be set the default config to OSC = INTIO67. GCB is not setting the INTOSC in config at all for the 18fxxk20 or 18fxxk22 families, although 16mhz intosc works because that is the POR default. Other families may or may not be affected.
If one can remember? the workaround is to set the config manually with #config OSC = INTIO67. There is no other problem to my knowledge, as the OSCCON and OSCTUNE (if the PLL is being used) registers are being set correctly.
Hi Kent. I only use 18f25k22 for pic use..I like it and have a few.
I have had no problems that I know using it at 16 or 64. I'm missing the point. Should I have been setting osc all the while? You have confused me.
Hey Stan, here is a simple test case. No output to the Terminal. No INTOSC in config output.
This compiled from v98 RC05, but I have same problem with other versions too.
What GCB version, and what is your asm output for the test program (with "no" #config operations)? Does this program work with a Terminal in your version?
@Kent,
This seems to be an issue with the chip data files, where 64, and 32 are missing from the Intosc listing in the [ChipData] section.
When I add 64 and 32 to the Intosc listing in 18F46K22.dat the ASM then shows:
We may also need to check the ASM INITSYS routine to make sure the PLL and OSCCON bits are properly set. But I suspect they will be.
Attached is a list of all PIC 18F Devices currently in production that support a 64MHz Clock. The datfiles for these chips will all need to be checked and corrected as necessary.
Last edit: William Roth 2017-09-19
@William,
Brilliant! I had looked at the chipdata file straight on and it did not even register to me that the missing Intosc settings were missing, good catch. Ha, I had thought this might have been a compiler problem.
Changed the 18f46k22 and 18k26k20 .dat files IntOsc= settings for 64, and 32, and all is well. Confirmed the config INTIO67 shows up now. For 32 and 64 mhz settings the INITSYS sub OSCCON bits and PLLEN bit of OSCTUNE set correctly. And, the hardware usart timing is now functioning properly for both settings.
Good news. So, I need a list of the chip files to update.
Does someone want to complete more analysis?
Or, do I simply update the database of chip data to set the internal oscillator to 64 using the data source provided by Bill?
We need some collective brain power.
Take the PIC18F26K22.
PIC18F26K22 according MAPS (the tool from Microchip) the max int osc is 32. This is data with an Excel spreadsheet.
PIC18F26K22 according the datasheet the max int osc is 64 with PLL.
Let us not debate the use of PLL etc. I need a reliable data source so we can make the correct setting in the chip database. I just need to know how to figure out whether to set the chip database to 64 - and, I am not willing to wade through 63 datasheets.
Take the 18F46K22.
The datasheet is more hopeful as this states 64 with PPL for the following 18 chips.
• PIC18F23K22 • PIC18LF23K22
• PIC18F24K22 • PIC18LF24K22
• PIC18F25K22 • PIC18LF25K22
• PIC18F26K22 • PIC18LF26K22
• PIC18F43K22 • PIC18LF43K22
• PIC18F44K22 • PIC18LF44K22
• PIC18F45K22 • PIC18LF45K22
• PIC18F46K22 • PIC18LF46K22
Summary, I just need a list of which chips should be set to Int Osc = 64.
:-)
So, I just just updated the chip database based upon this single datasheet. I have updated the datasource provided by Bill. The task is simple - what others?
Last edit: Anobium 2017-09-19
The datasheet for the 18f2xk20 and 18f4x20 says 64Mhz with PLL. So chips to change, time to snooz before checking others:
• PIC18F23K20
• PIC18F24K20
• PIC18F25K20
• PIC18F26K20
• PIC18F43K20
• PIC18F44K20
• PIC18F45K20
• PIC18F46K20
Another hiccup :)
Backchecked the hardware serial for the 18f26k20 and the 18f26k22.
For the 18f26k20 the INITSYS is not setting the OSCCON bits properly for "sub <16 chipmhz settings". For instance, with chipmhz of 8 the asm, OSCCON set to 112 which is the for 16mhz. Same type of problem for 4mhz, 1mhz. The HSerPrint baud rate suggests OSCCON OSC frequency settings are 2x what it should be:
'this is the asm for chipmhz of 8 INITSYS ;nop ' This is the routine for the OSCCON config nop ;OSCCON = OSCCON OR b'01110000' movlw 112 iorwf OSCCON,F,ACCESSFor 18f46k22 the hardware serial is good across tested range of chipmhz of 1,4,8,16,32,64.
@Kent. Please update the datasource (18f_64MHz Rev1.txt) else this will come off the rails and I will be totally confused. Change the revision number so I can track, and, attach to your posting.
And, can we resolve the .dat issue first - let fix the other issue later.
Last edit: Anobium 2017-09-19
Sourceforge is giving a 404 error for 18f_64MHZ Rev1.txt. I did however still have the original list from William still on the desktop.
So here is the progress to date on verifying 64mhz capability thru datasheets, and whether the GCB .dat sheet has correctly implemented IntOsc= 64,32,... some of them are OK by the looks of them.
I'm taking a break on verification.
OK, here is the last of the original list. No judgement is being made on PLL or DIV bits etc. I think the source files can be counted on to setting the MaxMHZ=64 correctly, and perhaps that how the list originated?
@Anobium,
The answer is NO.
Attached is new list with suggested additions to dat files "IntOsc =".
Pertaining to the 18f97J94 Family I have no suggestions due to the myriad of possibilities with USB devices.
Let me know if more info or help is needed. For instance if it just changing the .dat files, I could do that and zip them to you. If it is changing how you parse mchp .inc files or something else then no help.
Some background info.
We do not want to change the .dat files manually. I will regen the .dat files after we have corrected the chip database otherwise we will loose the changes in the future.
By changing the chip datase the 'IntOsc =' will be updated when I regen the all the chip .dat files. We have a number of other 'injectors' into the regen software to make forced changed to the Microchip INC files - the 'injectors' are the documented changes we need to change to resolve errors, mistakes and omissions within the Microchip INC files.
So, to update the "IntOsc =" I need to update the chip database to maintain consistency and quality of the dat file.
Makes sense?
Yes, thanks for the explanation.
Does this give more context to my Y / N question?
Do I use an as source to correct the chip database?
Yes appreciate the added information.
The NO becomes a YES with the "suggested additions to IntOsc=" in the 18F_64MHZ_REV1C.txt. As already noted by adding IntOsc = 64, 32 to the existing 18f46k22.dat file, produces the desired effect of allowing higher INTOSC speeds by default, now allows the CONFIG to be set to FOSC = INTIO67, and INITSYS OSCCON and PLL bits were being set properly.
Whether similar PIC K80 and K90 families will behave in a like manner way? There seems to be hope that they will. I manually added IntOsc= 64 to the 18f46k80.dat file and then compiled the hardware serial test case program. FOSC = INTIO2 is being set in CONFIG, and the INITSYS IRCF and PLLEN enable bits look good. Same for adding IntOsc = 64, 32 to the 18f65k90.dat file. Don't have examples of these devices to physically test.
Thank you. Just updating the library .... well Bill is doing this as he is world expect on this!
Thanks again.