The Great Cow BASIC chip config file. The file can be located in the ..GreatCowBasic\chipfile folder. Each file is specifically for a specific microcontroller. Look at the top and all the internal oscillator frequencies are shown. The INTOSC parameter.
The datasheet. The datasheet will also list the other possible setups for other oscillator types.
So, your little calculation will not calculate the frequency. You must refer to one of the sources stated above. I am sure there other sources but I use these sources to develop Great Cow BASIC.
Last edit: Anobium 2017-11-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So it seems like these frequencies are the only ones allowed. I guess I was set on the wrong foot by the help file. It says I could use any frequency I want, even with a decimal point.
Thanks for your help; a lot left to learn I guess.
Johan.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can set the clock to other frequencies but you have to put the PIC into EC or External Clock mode and then supply that specific clock frequency to the OSC1 pin.
There are three EC modes on the PIC12F1840:
ECL - 0 MHz - 0.5 MHz
ECM - 0.5 MHz - 4 MHz
ECH = 4 MHz - 32MHz
For a 2.1 MHz clock you would need to set the #config first:
#config OSC = ECM
Then the Clock Frequency
#chip 12f1840,2.1
Finally, supply the OSC1 pin with your 2.1 MHz signal.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The IntOsc line tells you what internal clock frequencies are supported. For example:
#chip 12F1840, 32
The ChipMHz of "32" does two things
when using the internal oscillator It tells the compiler to set the chip clock speed (FOSC) to 32MHz
It tells the compiler to calculate all delays (wait times) based upon FOSC of 32 MHz
Unlike Picaxe Basic, Great Cow delays ("wait") are correct regardless of the setting of FOSC. So you do not need to jump through hoops to get accurate timings with the wait command.
If you set the chipMhz to 4 a "wait 1 ms" will still be 1 ms.
If you set chipMhz to something other than the valid options in the[ChipData] IntOsc...then the compiler assumes that you are using an external oscillator and will calculate the delays according to the value you use. The wait times will be incorrect if you are not using an external oscillator as the same speed as ChipMhz.
Example: #chip 12F1840, 12
Since "12" is not a valid internal osc speed the chip FOSC will be 8 MHz because there is no external crystal and the chip falls back to the default 8MHz internal clock. However the wait times will be incorrect as they will be calculated by the compiler based upon a 12 Mhz clock.
Now have a look at the [ConfigOps] section of 12F1840.dat ( towards the end of the file)
OSC = Tells you what oscillator options are available. INTOSC is the internal oscillator. All others are some form of external clock source.
PLLEN sets the internal Phase Lock Loop either on or off. With this chip the default clock speed is 8 Mhz. The PLL multiplies this by 4. So to get 32 Mhz the basic internal oscillator will be 8 Mhz then multiplied by 4. For 16 MHz it wil be 4 multiplied by 4. But GCB sets the PLL automatically and this option should generally be left alone.
It is always a good practice to set the oscillator source in #config at the beginning of your code. This prevents potential errors. Example:
#Chip 12F1840, 16
#Config OSC = INTOSC
GCB will automatically set the necessary bits. Frequency bits will be set to 4 MHz and the PLL will be turned on and wait times will be calculated on an FOSC of 16,
Remember you are not using Picaxe Basic so it is best not to assume that GCB operates the same. It does not.
William
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With no "#config osc= " in the source code many chips default to an external oscillator source. This means at runtime the chip is expecting an external clock signal. However since the FCMEN bit is ON, the chip detects a "failure" of the external clock and then "falls back" to the internal oscillator. It only appears to default to INTOSC.
The PLLEN does not defaut to ON with any PIC chip that I am aware of. The PLL is enabled depending upon the ChipMhz in #Chip xxxxxx, ChipMhz
There are two possible default states in regard to the chip configuration bits.
1) The GCB default - This is how the bits are set if there is no #config in the source code, GCB does set certain bits. But to the best of my knowledfe this information is not published. To see what bits are set on a particular chip you can omit #config in the source code, then compile the code and then use "Open ASM" in the IDE. The bits that are set will be in the config section. All other bit ( those not specifically set will be at the POR setting as described below, The POR settings are shown in the datasheet for each PIC.
WARNING: GCB by default sets the LVP bit OFF on many chips. I am not sure of the thinking behind this as it does not affect normal HV programming, However it DOES disable the ability of the chip to be programmed via Low Voltage Programming, This means that a PIC chip that has previously been programmed with GCB code cannot be programmed in certain development boards e.g. "Curiosity". Programming will fail. It must be first reprogrammed with a HV programmmer such as Pickit 3 with the LVP bit =ON, before it can be used in one of these development boards. I almost always set LVP = ON in my source code to prevent this issue.
2) The native POR (Power On Reset) defaults. This is the state of the config bits after Power on if the ASM code has no configuration entries or on a blank factory chip. The only way to power up in this state with GCB code is to use " #option NoConfig" in the BASIC source code. This oprion is generally used when the chip has a bootloader installed. It can also be used for troubleshooting.
William
Last edit: William Roth 2017-11-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Whoa now, lots of chips with no LVP or PGM pin (12f685, 16f684 etc.). The LVP=OFF was instituted way back when Hugh was lifting GCB off the ground and developing a GCB default config setting. Yes everyone is a newbie sometime ;-) https://sourceforge.net/p/gcbasic/discussion/579126/thread/cf98553a/?limit=25#133f/6475/252c/5b29 Back then the LVP bit was not accounted for and caused GCB to not produce a hex file. I am sure that it is accounted for now with the .dat files.
All the GCB code that has been developed to blow the MCLR fuse (HVP only) for use as an input will be disenfranchised now? Is the greater good of past projects or code being served if LVP=ON is now default for the relatively new (and few?) development boards?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Haha yes, the clock settings allow you go makes things even slower...
In fact, that's what I was trying to do. I read that the ECL-mode allows FOSC from 0 to 0.5 MHz. That fascinated me. Just for fun, the idea was to clock the OSC1.CLKIN by hand to see how many cycles it would take to toggle a led. First I made a 1Hz generator to try the concept. It didn't work. Checking the datasheet I found that the FCMEN is a fail safe monitor that switches back to the internal oscillator when the external frequency is lower then 488Hz.
The FCMEN can be disabled but it didn't find that option in GCB yet.
Last edit: JohanDenRidder 2017-11-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you use <1MHz the pwm can run a servo actuator instead of pulse out ie you get lots of period values that apply. What happens if you use a watch xtal, 32.768KHz? set watch dog timer?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was not necessarily suggesting a change in the default LVP. More of a warning than anything given the popularity of the Curiosity Boards and the recent discovery of the NS boards.
Another thing to consider is that with LVP = ON.... MCLR will be automatically set to external MCLR and the MCLRE Config bit will be ignored. I never use the MCLR pin for I/O duties, opting instead to use a chip with more pins if necessary.
Others may want to use the MCLR pin for I/O stuff. In that case LVP must be OFF and MCLR must be set to INTERNAL. But then, of course, these Low Voltage Programmers will no longer work with the with the chip.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It surprised me a little that it actually does work. I used a second PIC to generate 1Hz as a clock frequency.
The first PIC generates 50kHz when running on the internal 1MHz oscillator:
It is kind of funny. I have a LED on the 1Hz clock so I can literally count the cycles that the PIC needs to go through the loop. It takes 20 cycles in total. The output is high for 4 cycles and low for 16 cycles.
It is more for fun than anything else, but running a microcontroller on 1Hz (or lower) could have its applications :)
At one time the ouput was 2.5 Hz in stead of the expected 0.04 Hz. The connection between clock generator and the first PIC was loose causing the sensitive Schmitt-trigger input OSC1/CLKIN switching at 50Hz (mains frequency in the Netherlands).
Johan
Last edit: JohanDenRidder 2017-11-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to the help file the clock frequency can be set by command #chip 12F1840,MHz
I can't find what parameters really work.
I tried this:
rem #chip 12f1840,32
dir portA out
do
portA.2 = NOT portA.2
loop
It generates a square wave at the output of 290 kHz (with the 'rem' removed from the first line)
Now if I try other parameters one would expect the output frequency to be linear with the clock grequency, but this is what I get:
command > output freq. kHz
chip 12F1840 = 290
chip 12F1840,1 = 9
chip 12F1840,2 = 18
chip 12F1840,3 = 5
chip 12F1840,4 = 36
chip 12F1840,5 = 5
chip 12F1840,6 = 5
chip 12F1840,7 = 5
chip 12F1840,8 = 73
chip 12F1840,9 = 5
chip 12F1840,10 = 5
chip 12F1840,11 = 5
chip 12F1840,12 = 5
chip 12F1840,13 = 5
chip 12F1840,14 = 5
chip 12F1840,15 = 5
chip 12F1840,16= 145
chip 12F1840,17 = 5
chip 12F1840,18 = 5
chip 12F1840,19 = 5
chip 12F1840,20 = 5
chip 12F1840,21 = 5
chip 12F1840,22 = 5
chip 12F1840,23 = 5
chip 12F1840,24 = 73
chip 12F1840,25 = 5
chip 12F1840,26 = 5
chip 12F1840,27 = 5
chip 12F1840,28 = 5
chip 12F1840,29 = 5
chip 12F1840,30 = 5
chip 12F1840,31 = 5
chip 12F1840,32 = 290
These frequencies are all factors of 290 kHz, factor (factor 1, 2, 4,8,16, 32 and 64)
Is there a logical explanation for this?
Johan
Last edit: JohanDenRidder 2017-11-21
Thought it was divisions of clock. 64,32,16,8,4,2,1 but no expert
Two places to look
So, your little calculation will not calculate the frequency. You must refer to one of the sources stated above. I am sure there other sources but I use these sources to develop Great Cow BASIC.
Last edit: Anobium 2017-11-21
It is not a calculation, it is what I measured at the output pin.
I tried 33 different parameters and measured the frequency after each compilation.
Last edit: JohanDenRidder 2017-11-21
In the 12F1840.dat file I found this line:
IntOsc=32, 16, 8, 4, 2, 1, 0.5, 0.25, 0.125
So it seems like these frequencies are the only ones allowed. I guess I was set on the wrong foot by the help file. It says I could use any frequency I want, even with a decimal point.
Thanks for your help; a lot left to learn I guess.
Johan.
Remind me. Are you ex-Picaxe? Those two files and SO much information. :-)
The reason for the results.... my guess, others will wade is now.... that the backup osc started up.
Yes, I am ex-Picaxe. So I'm exited about this new environment.
Not sure what two files you are referring to however.
You can set the clock to other frequencies but you have to put the PIC into EC or External Clock mode and then supply that specific clock frequency to the OSC1 pin.
There are three EC modes on the PIC12F1840:
ECL - 0 MHz - 0.5 MHz
ECM - 0.5 MHz - 4 MHz
ECH = 4 MHz - 32MHz
For a 2.1 MHz clock you would need to set the #config first:
Then the Clock Frequency
Finally, supply the OSC1 pin with your 2.1 MHz signal.
Each chip has a chip data file. This file is located in /GreatCowBasic/chipdata/
Example: 12F1840.dat
The relevant sections in regards to "chip mhz" are
[ChipData] and [ConfigOps]
Here is the ChipData section for 12F1840
The IntOsc line tells you what internal clock frequencies are supported. For example:
The ChipMHz of "32" does two things
when using the internal oscillator It tells the compiler to set the chip clock speed (FOSC) to 32MHz
It tells the compiler to calculate all delays (wait times) based upon FOSC of 32 MHz
Unlike Picaxe Basic, Great Cow delays ("wait") are correct regardless of the setting of FOSC. So you do not need to jump through hoops to get accurate timings with the wait command.
If you set the chipMhz to 4 a "wait 1 ms" will still be 1 ms.
If you set chipMhz to something other than the valid options in the[ChipData] IntOsc...then the compiler assumes that you are using an external oscillator and will calculate the delays according to the value you use. The wait times will be incorrect if you are not using an external oscillator as the same speed as ChipMhz.
Example: #chip 12F1840, 12
Since "12" is not a valid internal osc speed the chip FOSC will be 8 MHz because there is no external crystal and the chip falls back to the default 8MHz internal clock. However the wait times will be incorrect as they will be calculated by the compiler based upon a 12 Mhz clock.
Now have a look at the [ConfigOps] section of 12F1840.dat ( towards the end of the file)
OSC = Tells you what oscillator options are available. INTOSC is the internal oscillator. All others are some form of external clock source.
PLLEN sets the internal Phase Lock Loop either on or off. With this chip the default clock speed is 8 Mhz. The PLL multiplies this by 4. So to get 32 Mhz the basic internal oscillator will be 8 Mhz then multiplied by 4. For 16 MHz it wil be 4 multiplied by 4. But GCB sets the PLL automatically and this option should generally be left alone.
It is always a good practice to set the oscillator source in #config at the beginning of your code. This prevents potential errors. Example:
GCB will automatically set the necessary bits. Frequency bits will be set to 4 MHz and the PLL will be turned on and wait times will be calculated on an FOSC of 16,
Remember you are not using Picaxe Basic so it is best not to assume that GCB operates the same. It does not.
William
@Bill. A good explanation. Can you find time to update the Help? Online here https://github.com/Anobium/Great-Cow-BASIC-Help/blob/master/source/chip.adoc
That is fascinating. It is opening a new world coming from Picaxe.
I understand that OSC default = INTOSC and the PLLEN default= ON. Is there a source where to find these defaults?
Actually that is not correct.
With no "#config osc= " in the source code many chips default to an external oscillator source. This means at runtime the chip is expecting an external clock signal. However since the FCMEN bit is ON, the chip detects a "failure" of the external clock and then "falls back" to the internal oscillator. It only appears to default to INTOSC.
The PLLEN does not defaut to ON with any PIC chip that I am aware of. The PLL is enabled depending upon the ChipMhz in #Chip xxxxxx, ChipMhz
There are two possible default states in regard to the chip configuration bits.
1) The GCB default - This is how the bits are set if there is no #config in the source code, GCB does set certain bits. But to the best of my knowledfe this information is not published. To see what bits are set on a particular chip you can omit #config in the source code, then compile the code and then use "Open ASM" in the IDE. The bits that are set will be in the config section. All other bit ( those not specifically set will be at the POR setting as described below, The POR settings are shown in the datasheet for each PIC.
WARNING: GCB by default sets the LVP bit OFF on many chips. I am not sure of the thinking behind this as it does not affect normal HV programming, However it DOES disable the ability of the chip to be programmed via Low Voltage Programming, This means that a PIC chip that has previously been programmed with GCB code cannot be programmed in certain development boards e.g. "Curiosity". Programming will fail. It must be first reprogrammed with a HV programmmer such as Pickit 3 with the LVP bit =ON, before it can be used in one of these development boards. I almost always set LVP = ON in my source code to prevent this issue.
2) The native POR (Power On Reset) defaults. This is the state of the config bits after Power on if the ASM code has no configuration entries or on a blank factory chip. The only way to power up in this state with GCB code is to use " #option NoConfig" in the BASIC source code. This oprion is generally used when the chip has a bootloader installed. It can also be used for troubleshooting.
William
Last edit: William Roth 2017-11-23
LVP should be ON by default. It is not then we should look into the specifics of why this is not happening.
Whoa now, lots of chips with no LVP or PGM pin (12f685, 16f684 etc.). The LVP=OFF was instituted way back when Hugh was lifting GCB off the ground and developing a GCB default config setting. Yes everyone is a newbie sometime ;-) https://sourceforge.net/p/gcbasic/discussion/579126/thread/cf98553a/?limit=25#133f/6475/252c/5b29 Back then the LVP bit was not accounted for and caused GCB to not produce a hex file. I am sure that it is accounted for now with the .dat files.
All the GCB code that has been developed to blow the MCLR fuse (HVP only) for use as an input will be disenfranchised now? Is the greater good of past projects or code being served if LVP=ON is now default for the relatively new (and few?) development boards?
Let me speak with Hugh - give us a day or two.
Cheers
Many things need recalculating if you change picaxe clock frequency. Pulse out, pwm. Programs go from slow to dead slow :)
Haha yes, the clock settings allow you go makes things even slower...
In fact, that's what I was trying to do. I read that the ECL-mode allows FOSC from 0 to 0.5 MHz. That fascinated me. Just for fun, the idea was to clock the OSC1.CLKIN by hand to see how many cycles it would take to toggle a led. First I made a 1Hz generator to try the concept. It didn't work. Checking the datasheet I found that the FCMEN is a fail safe monitor that switches back to the internal oscillator when the external frequency is lower then 488Hz.
The FCMEN can be disabled but it didn't find that option in GCB yet.
Last edit: JohanDenRidder 2017-11-24
If you use <1MHz the pwm can run a servo actuator instead of pulse out ie you get lots of period values that apply. What happens if you use a watch xtal, 32.768KHz? set watch dog timer?
I was not necessarily suggesting a change in the default LVP. More of a warning than anything given the popularity of the Curiosity Boards and the recent discovery of the NS boards.
Another thing to consider is that with LVP = ON.... MCLR will be automatically set to external MCLR and the MCLRE Config bit will be ignored. I never use the MCLR pin for I/O duties, opting instead to use a chip with more pins if necessary.
Others may want to use the MCLR pin for I/O stuff. In that case LVP must be OFF and MCLR must be set to INTERNAL. But then, of course, these Low Voltage Programmers will no longer work with the with the chip.
It surprised me a little that it actually does work. I used a second PIC to generate 1Hz as a clock frequency.
The first PIC generates 50kHz when running on the internal 1MHz oscillator:
If I use the external oscillator the PIC generates 0.05Hz. That is the LED goes on for 4 seconds then off for 16 seconds:
Johan
I forgot about the FCMEN bit. Good catch.
It is kind of funny. I have a LED on the 1Hz clock so I can literally count the cycles that the PIC needs to go through the loop. It takes 20 cycles in total. The output is high for 4 cycles and low for 16 cycles.
It is more for fun than anything else, but running a microcontroller on 1Hz (or lower) could have its applications :)
At one time the ouput was 2.5 Hz in stead of the expected 0.04 Hz. The connection between clock generator and the first PIC was loose causing the sensitive Schmitt-trigger input OSC1/CLKIN switching at 50Hz (mains frequency in the Netherlands).
Johan
Last edit: JohanDenRidder 2017-11-24
This should "balance" the on/off times and compenate for jump associated with a do-loop
Almost, the duty cycle is now 42.8%.
The output is on for 12 cycles and off for 16 cycles.
I changed your suggestion to this:
Now it is 50% duty cycle, 12 cycles on and 12 cycles off.
Johan
Last edit: JohanDenRidder 2017-11-24