Hi, pretty new on PIC programming.
Just tried to create a walking LED with 3 outputs on this low end PIC
GP2 is shared with TOCS so I have to disable TOCS output in this pin.
I cannot find how to override the TOCS precedence. I know I have to clear bit five on the option register but cannot find out how to do this in code.
I tried :
asm MOVLW b'11011111'
asm OPTION
but that won't work.
I'm using the internal osc and no fancy stuff. Even use sequential output code.
Here is the code so far:
; ----- Configuration
#chip 10f200, 4
; ----- Constants
#define LED0 GPIO.0
#define LED1 GPIO.1
#define LED2 GPIO.2
asm MOVLW b'11011111'
asm OPTION
; ----- Define Hardware settings
dir LED0 out
dir LED1 out
dir LED2 out
; ----- Variables
' No Variables specified in this example. All byte variables are defined upon use.
; ----- Main body of program commences here.
Do
LED0 = FnNotBit( LED0 ) ' LED != LED
wait 100 ms
LED1 = FnNotBit( LED1 ) ' LED != LED
wait 100 ms
LED2 = FnNotBit( LED2 ) ' LED != LED
wait 100 ms
Loop
end
thank for helping me out :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Program works fine in 95.008, so newer uploads should be O.K., which version do you have? Wiring, led orientation, or other problem here?
GCB is happy to set the option register for you in the default INITSYS sub, so no real need to set OPTION unless there are other reasons. Default OPTION register setting is b'11000111', which handles the TOCK pin.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have the latest windows version (0.96.00) installed in a virtual box using the Synwrite IDE
I have GCB installed under linux too. Will try to compile there and report back
Wiring or LED orientation cannot be the case. Iḿ using a breakout LED board with integrated resitors. Just one wire to GND and a wire to the output LED
so IC pin 5 -> Led Board 0, IC pin 4 -> LED board 1 and IC pin 3 -> LED board 2
LED 0 and 1 are flashing, LED 2 lights up on half power. On my scope there is a 50% duty cycle pulse from the clock
Compiling & linking in Linux gives me the same results. Latest gcbasic version (0.96 for linux) on Linux Mint. I hooked up the datalogger. As you can see there is a 1 Mhz pulse on GPIO2
Seeing equal power between LED1 and LED2, LED0 not checked because different led. I thought that LED2 was also down on power, but when looked at directly (due to narrow emitter angle) from above they are the same brightness. You have checked milliamps?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK then, need help from Anobium (Evan) here. OSCCAL doesn't really need to be set in INITSYS, cut and paste issue? And in doing so, it is not being set correctly OSCCAL = b'11000111' so bit0 is setting the INTOSC/4 to output on GP2.
EDIT: I know 95.008 works properly, or you can rewrite OSCCAL with bit0 = 0 in main to overwrite INITSYS till a fix is in.
Last edit: kent_twt4 2017-02-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Kent is correct. We are incorrectly setting OSCCAL. This is not a typo but an error when we extended the code to support some differing chip types.
Meanwhile... try this. I did simplfy the code. :-)
; ----- Configuration
#chip 10f200, 4
OSCCAL.0 = 0
; ----- Constants
#define LED0 GPIO.0
#define LED1 GPIO.1
#define LED2 GPIO.2
; ----- Define Hardware settings
dir LED0 out
dir LED1 out
dir LED2 out
; ----- Variables
' No Variables specified in this example. All byte variables are defined upon use.
; ----- Main body of program commences here.
Do
LED0 = !LED0
wait 100 ms
LED1 = !LED1
wait 100 ms
LED2 = !LED2
wait 100 ms
Loop
end
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Try this - but, on relfection... this is just fyi. Does not resolve. We are having a discussion in the DEV forum to resolve. The issue is not a cut and paste issue but a constraint we may not have applied - I the brains of the Dev team!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for not responding earlier, had to catch some sleep :)
Update:
A installed 0.95 and that worked without a problem, just to be sure, although I had to change the FnNotBit part because that is an unknown function in 0.95
Back to the latest release, simplified and optimised the code to this
'''@author R. de Vreugd
'''@licence GPL
'''@version 1.02a
'''@date 10.02.2017
'''********************************************************************************
; ----- Configuration
#chip 10f200, 4
OSCCAL.0 = 0 ; work around?
; ----- Constants
#define LED0 GPIO.0
#define LED1 GPIO.1
#define LED2 GPIO.2
; ----- Define Hardware settings
dir LED0 out
dir LED1 out
dir LED2 out
; ----- Variables
' No Variables specified in this example. All byte variables are defined upon use.
; ----- Quick Command Reference:
'See header for details
; ----- Main body of program commences here.
Do
LED0 = !LED0 ' LED != LED
pause
LED1 = !LED1 ' LED != LED
pause
LED2 = !LED2 ' LED != LED
pause
Loop
end
; ----- Support methods. Subroutines and Functions
sub pause
wait 100 ms
end sub
note the OSCCAL.0 = 0 as a workaround (thanks Anobium)
That workaround did the trick, see the attached screenshot of my logger
The previous post is the 0.96 version. To be sure I tried the code in an older version without the OSCCAL.0 = 0 and that worked.
The code and output you see in te previous post is used and compiled with the latest IDE version in Windows (0.96) and the linux (ubuntu.MINT) version.
On these versions the clock pulse on the output pin is NOT disabled. You have to use the workaround you posted some messages ago using OSCCAL.0 = 0
Then the result is as expected.
off topic: Just entered the amazing wold of PIC programming. Used MPLAB X both in assembler and X8C but was not thrilled. I must say I really do like GCB and I am very surprised about these community responses. Think I will stick with GCB for a long time :) Keep it up guys!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What are you using to program the chip? we believe that you have knocked out the calibration. We need to know what you are using to program.
Why does 0.95 and not 0.96. 0,95 ran the chip uncalibrated... not good. 0.96 has the correct call to setup the chip at the calibrated clock speed. So, we believe (at the moment), the code is valid.
Let us know. We are all waiting to here!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For this project I used an K150 programmer. Removing the chip from the breadboard, program it en replace it. If you like I could try a pickit 2 as that is in my toolbox too. A pickit 3 is on it's way.
To be sure:
Version 0.96 with K150 no OSCCAL.0=0 --> clock on output
Version 0.96 with K150 with OSCCAL.0=0 --> correct running LEDs
Version 0.95 with K150 no OSCCAL.0=0 -> correct running LEDs
PicKit 2, I hav eto try, but I am out for a few hours, will do when I get back
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
AHA! the K150 has knocked out the calibration. The PK2 and PK3 will sort this with our build of the software. Please installed the software included in your GCB for the pk2 and/or the pk3.
Anyway, you need to restore the calibration and all 'should' be ok. My OSCCAL value is 0CFF on my 10F202.
I am sure others can tell you how to re-calibate but if it does not fix it.. use the OSCCAL=0 and press on!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My 10f200 OSCCAL=0C24. From what I can tell, the 10f200,202,204,206,220,222 has the FOSC4 bit in OSCCAL.0 Other baseline chips like 12f508,509 have no FOSC4/OSCCAL.0 bit.
The Pk2 has the OSCCAL auto calibrate function under the tools header of the GUI. Pk3 can do this too under the MPLAB IPE.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok gents her I am again.
Think I have to disappoint you :(
An update of my new actions:
Stashed the K150 and hooked up the PK2 first stand alone, so remove the chip from the breadboard. Create a hex file with GCB (0.96) and write the hex with the PK2 util
Did that with osccal.0=0 in the code and again commented out.
Second I did exactly the same but now in circuit powered by the PK2
My OSCCAL calibration is 0CFF and is preserved on write.
So there is no need to restore calibration.
Here are the results:
off circuit, osccal.0 set in code -> working correct
off circuit, osccal.0 removed -> clockpulse on output pin 2
in circuit, OSCCAL.0 set in code -> working correct
in circuit, OSCCAL.0 removed -> clockpulse on output pin 2
Sorry we are back to square one. The programmer is ruled out result are the same for the K150 and the PK2 and ther is nothing wrong with my calibration. Tried again with a brand new spare 10f200 with same results.
*BTW: this is not a simple experiment. In the end I want to create a small battery operated device that pulses a IR led (GP0), read the pulses back on GP3 and if interupted opens the shutter of a camera (GP1) and activates a flash (GP2). *
EDIT: if you check the datlogger output a few messages ago you can see that the clock pulse is 1.083 us. Well within limits of the specs from the internal osc and the values in the datasheet (in theory the pulswidth should be 1us)
Last edit: Ruud de Vreugd 2017-02-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Use OSCCAL auto regenerate in Pk2 and tell us the results, in circuit is the way to go.
This seems very odd that OSCCAL is 0CFF, that is the default? number that pops up when first opening Pk2 and selecting the device, or changing to a different device, but not after programming or reading the device.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An OSCCAL value of 0x0CFF seems odd. The 0C is the MOVLW instruction an is of no concern. However the FF indicates that the chip calibration is set to near center frequency with bit 0 on. FF is the default and is unlikely to be the best calibration value.
If we write this value of FF to the OSCCAL register via the routine in system.h then bit 0 will be on. A calibration value of 0CFE seems more appropriate.
I would try the automatic calibration feature in the Pick2 GUI and see what value it selects. If the utility is "smart" it will write an even value where bit 0 is off, If it is not "smart" it could write an odd value where bit 0 is ON. In this case it could be modified by manually setting the calibration value.
The other option is to mask out bit 0 in source code. As this will not affect the OSC calibration.
A better check of accurate calibration is to do a "wait 10 ms" and measure with a scope as as the error will accumulate. over time and be more visible. Microsecond measurements are not accurate.
1.083 us X 10000 = 10.83 ms and we can do better than that with the correct calibration value. In fact 10.83 ms is what I get when I delete the calibation data on a 12F510. With the autogenerated value from PK2 GUI it improves to 10. 07 ms
EDIT:
The OSC on these chips is supposed to be factory calibrated to +- %1. So if we assume that 1.083us is an accurate measurement we are out of specification by 8%. It should be between .99us and 1.01 us.
Last edit: William Roth 2017-02-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK guys,
I guess you are right. I used the auto calibration of the PK2. The selected value came out on 0C16 (even value). From that moment on everything works as it should be. I do not have to set the OSCCAL manualy. So it really was a bad calibration value. Is that caused by the K150??
Set the wait time at 10ms to measure the values wit the datalogger like William sugested.
Measured value 10.035ms. Some siple math gives me a clockpulse of 1.0035us
I love this community. I had never ever found this on my own.
thanks
Last edit: Ruud de Vreugd 2017-02-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, pretty new on PIC programming.
Just tried to create a walking LED with 3 outputs on this low end PIC
GP2 is shared with TOCS so I have to disable TOCS output in this pin.
I cannot find how to override the TOCS precedence. I know I have to clear bit five on the option register but cannot find out how to do this in code.
I tried :
but that won't work.
I'm using the internal osc and no fancy stuff. Even use sequential output code.
Here is the code so far:
; ----- Configuration #chip 10f200, 4 ; ----- Constants #define LED0 GPIO.0 #define LED1 GPIO.1 #define LED2 GPIO.2 asm MOVLW b'11011111' asm OPTION ; ----- Define Hardware settings dir LED0 out dir LED1 out dir LED2 out ; ----- Variables ' No Variables specified in this example. All byte variables are defined upon use. ; ----- Main body of program commences here. Do LED0 = FnNotBit( LED0 ) ' LED != LED wait 100 ms LED1 = FnNotBit( LED1 ) ' LED != LED wait 100 ms LED2 = FnNotBit( LED2 ) ' LED != LED wait 100 ms Loop endthank for helping me out :)
Program works fine in 95.008, so newer uploads should be O.K., which version do you have? Wiring, led orientation, or other problem here?
GCB is happy to set the option register for you in the default INITSYS sub, so no real need to set OPTION unless there are other reasons. Default OPTION register setting is b'11000111', which handles the TOCK pin.
I have the latest windows version (0.96.00) installed in a virtual box using the Synwrite IDE
I have GCB installed under linux too. Will try to compile there and report back
Wiring or LED orientation cannot be the case. Iḿ using a breakout LED board with integrated resitors. Just one wire to GND and a wire to the output LED
so IC pin 5 -> Led Board 0, IC pin 4 -> LED board 1 and IC pin 3 -> LED board 2
LED 0 and 1 are flashing, LED 2 lights up on half power. On my scope there is a 50% duty cycle pulse from the clock
Compiling & linking in Linux gives me the same results. Latest gcbasic version (0.96 for linux) on Linux Mint. I hooked up the datalogger. As you can see there is a 1 Mhz pulse on GPIO2
Last edit: Ruud de Vreugd 2017-02-10
Seeing equal power between LED1 and LED2, LED0 not checked because different led. I thought that LED2 was also down on power, but when looked at directly (due to narrow emitter angle) from above they are the same brightness. You have checked milliamps?
see previous post with screenshot
O.K. so still TOCK out, can you post your assembly file.
sure, this is the assembly file from the linux compiler:
in initsys option is set correct as you can see ???
OK then, need help from Anobium (Evan) here. OSCCAL doesn't really need to be set in INITSYS, cut and paste issue? And in doing so, it is not being set correctly OSCCAL = b'11000111' so bit0 is setting the INTOSC/4 to output on GP2.
EDIT: I know 95.008 works properly, or you can rewrite OSCCAL with bit0 = 0 in main to overwrite INITSYS till a fix is in.
Last edit: kent_twt4 2017-02-10
Thanks... see http://gcbasic.sourceforge.net/help/compilerinsights.html as a start. This will explain the changes we made to support these chips.
I need look into the issue. Back later.
I need to discuss with the dev team.
@Kent is correct. We are incorrectly setting OSCCAL. This is not a typo but an error when we extended the code to support some differing chip types.
Meanwhile... try this. I did simplfy the code. :-)
; ----- Configuration #chip 10f200, 4 OSCCAL.0 = 0 ; ----- Constants #define LED0 GPIO.0 #define LED1 GPIO.1 #define LED2 GPIO.2 ; ----- Define Hardware settings dir LED0 out dir LED1 out dir LED2 out ; ----- Variables ' No Variables specified in this example. All byte variables are defined upon use. ; ----- Main body of program commences here. Do LED0 = !LED0 wait 100 ms LED1 = !LED1 wait 100 ms LED2 = !LED2 wait 100 ms Loop endThe link is not working.
http://gcbasic.sourceforge.net/help/_compiler_insights.html
Try this - but, on relfection... this is just fyi. Does not resolve. We are having a discussion in the DEV forum to resolve. The issue is not a cut and paste issue but a constraint we may not have applied - I the brains of the Dev team!!
Sorry for not responding earlier, had to catch some sleep :)
Update:
A installed 0.95 and that worked without a problem, just to be sure, although I had to change the FnNotBit part because that is an unknown function in 0.95
Back to the latest release, simplified and optimised the code to this
'''@author R. de Vreugd '''@licence GPL '''@version 1.02a '''@date 10.02.2017 '''******************************************************************************** ; ----- Configuration #chip 10f200, 4 OSCCAL.0 = 0 ; work around? ; ----- Constants #define LED0 GPIO.0 #define LED1 GPIO.1 #define LED2 GPIO.2 ; ----- Define Hardware settings dir LED0 out dir LED1 out dir LED2 out ; ----- Variables ' No Variables specified in this example. All byte variables are defined upon use. ; ----- Quick Command Reference: 'See header for details ; ----- Main body of program commences here. Do LED0 = !LED0 ' LED != LED pause LED1 = !LED1 ' LED != LED pause LED2 = !LED2 ' LED != LED pause Loop end ; ----- Support methods. Subroutines and Functions sub pause wait 100 ms end subnote the OSCCAL.0 = 0 as a workaround (thanks Anobium)
That workaround did the trick, see the attached screenshot of my logger
Ruud
Can you try the code using 0.96.00? We will only fix 0.96.00 and later releases?
The previous post is the 0.96 version. To be sure I tried the code in an older version without the OSCCAL.0 = 0 and that worked.
The code and output you see in te previous post is used and compiled with the latest IDE version in Windows (0.96) and the linux (ubuntu.MINT) version.
On these versions the clock pulse on the output pin is NOT disabled. You have to use the workaround you posted some messages ago using OSCCAL.0 = 0
Then the result is as expected.
off topic: Just entered the amazing wold of PIC programming. Used MPLAB X both in assembler and X8C but was not thrilled. I must say I really do like GCB and I am very surprised about these community responses. Think I will stick with GCB for a long time :) Keep it up guys!
@Ruud de Vreugd. Nothing looks incorrect.
What are you using to program the chip? we believe that you have knocked out the calibration. We need to know what you are using to program.
Why does 0.95 and not 0.96. 0,95 ran the chip uncalibrated... not good. 0.96 has the correct call to setup the chip at the calibrated clock speed. So, we believe (at the moment), the code is valid.
Let us know. We are all waiting to here!!
For this project I used an K150 programmer. Removing the chip from the breadboard, program it en replace it. If you like I could try a pickit 2 as that is in my toolbox too. A pickit 3 is on it's way.
To be sure:
Version 0.96 with K150 no OSCCAL.0=0 --> clock on output
Version 0.96 with K150 with OSCCAL.0=0 --> correct running LEDs
Version 0.95 with K150 no OSCCAL.0=0 -> correct running LEDs
PicKit 2, I hav eto try, but I am out for a few hours, will do when I get back
AHA! the K150 has knocked out the calibration. The PK2 and PK3 will sort this with our build of the software. Please installed the software included in your GCB for the pk2 and/or the pk3.
Anyway, you need to restore the calibration and all 'should' be ok. My OSCCAL value is 0CFF on my 10F202.
I am sure others can tell you how to re-calibate but if it does not fix it.. use the OSCCAL=0 and press on!
My 10f200 OSCCAL=0C24. From what I can tell, the 10f200,202,204,206,220,222 has the FOSC4 bit in OSCCAL.0 Other baseline chips like 12f508,509 have no FOSC4/OSCCAL.0 bit.
The Pk2 has the OSCCAL auto calibrate function under the tools header of the GUI. Pk3 can do this too under the MPLAB IPE.
Ok gents her I am again.
Think I have to disappoint you :(
An update of my new actions:
Stashed the K150 and hooked up the PK2 first stand alone, so remove the chip from the breadboard. Create a hex file with GCB (0.96) and write the hex with the PK2 util
Did that with osccal.0=0 in the code and again commented out.
Second I did exactly the same but now in circuit powered by the PK2
My OSCCAL calibration is 0CFF and is preserved on write.
So there is no need to restore calibration.
Here are the results:
off circuit, osccal.0 set in code -> working correct
off circuit, osccal.0 removed -> clockpulse on output pin 2
in circuit, OSCCAL.0 set in code -> working correct
in circuit, OSCCAL.0 removed -> clockpulse on output pin 2
Sorry we are back to square one. The programmer is ruled out result are the same for the K150 and the PK2 and ther is nothing wrong with my calibration. Tried again with a brand new spare 10f200 with same results.
*BTW: this is not a simple experiment. In the end I want to create a small battery operated device that pulses a IR led (GP0), read the pulses back on GP3 and if interupted opens the shutter of a camera (GP1) and activates a flash (GP2). *
EDIT: if you check the datlogger output a few messages ago you can see that the clock pulse is 1.083 us. Well within limits of the specs from the internal osc and the values in the datasheet (in theory the pulswidth should be 1us)
Last edit: Ruud de Vreugd 2017-02-10
Use OSCCAL auto regenerate in Pk2 and tell us the results, in circuit is the way to go.
This seems very odd that OSCCAL is 0CFF, that is the default? number that pops up when first opening Pk2 and selecting the device, or changing to a different device, but not after programming or reading the device.
An OSCCAL value of 0x0CFF seems odd. The 0C is the MOVLW instruction an is of no concern. However the FF indicates that the chip calibration is set to near center frequency with bit 0 on. FF is the default and is unlikely to be the best calibration value.
If we write this value of FF to the OSCCAL register via the routine in system.h then bit 0 will be on. A calibration value of 0CFE seems more appropriate.
I would try the automatic calibration feature in the Pick2 GUI and see what value it selects. If the utility is "smart" it will write an even value where bit 0 is off, If it is not "smart" it could write an odd value where bit 0 is ON. In this case it could be modified by manually setting the calibration value.
The other option is to mask out bit 0 in source code. As this will not affect the OSC calibration.
A better check of accurate calibration is to do a "wait 10 ms" and measure with a scope as as the error will accumulate. over time and be more visible. Microsecond measurements are not accurate.
1.083 us X 10000 = 10.83 ms and we can do better than that with the correct calibration value. In fact 10.83 ms is what I get when I delete the calibation data on a 12F510. With the autogenerated value from PK2 GUI it improves to 10. 07 ms
EDIT:
The OSC on these chips is supposed to be factory calibrated to +- %1. So if we assume that 1.083us is an accurate measurement we are out of specification by 8%. It should be between .99us and 1.01 us.
Last edit: William Roth 2017-02-11
OK guys,
I guess you are right. I used the auto calibration of the PK2. The selected value came out on 0C16 (even value). From that moment on everything works as it should be. I do not have to set the OSCCAL manualy. So it really was a bad calibration value. Is that caused by the K150??
Set the wait time at 10ms to measure the values wit the datalogger like William sugested.
Measured value 10.035ms. Some siple math gives me a clockpulse of 1.0035us
I love this community. I had never ever found this on my own.
thanks
Last edit: Ruud de Vreugd 2017-02-11
Looks like we have a resolution. All pins working as expected and an accurate OSC.
Yes, IMO it was most likely the K150 Programmer that erased the calibration data, .
And BTW ....... Welcome to Great Cow Basic !
Just to correct my info of the earlier post my OSCCAL on the 10F202 on test here is 0x0C0E which does give me a 10,00ms width for a 'wait 10 ms'
Result.
Oh.... Welcome to Great Cow BASIC. Enjoy.
Last edit: Anobium 2017-02-11