Hi all, it’s the PIC virgin again. I have a simple program to turn on a pump for 100 seconds. The measured on time is variable from about 60 sec. to about 80 seconds. I do not understand why it is not 100 sec. and varies from each time it is activated.
The measured cycle time is about 1 Hz as it should be.
Also the crowbar should not have more than a 1 sec delay, however it does not function until the timer has timed out and the pump is shut off!. Can anyone help out? Regards, Ed.
'A program to run a gas pump and to detect an overfill and crowbar the output
'Chip model
#chip 12F675, 4
#config osc=int
'Set the pin directions
dir gpio.4 in 'Low gas signal
dir gpio.3 in 'Overflow signal
dir gpio.1 out 'Crowbar output
dir gpio.2 out 'Pump output
dir gpio.0 out 'Test point
'initialize outputs and timer
set gpio.1 off
set gpio.2 off
timer = 0
'Main routine
Start:
pulseout gpio.0, 1 ms 'test cycle time
gosub crowbar
gosub pump
goto Start
sub crowbar 'shuts down everything
if gpio.3 = on then set gpio.1 on
end sub
sub pump 'turns on pump for a period of time
timer = timer +1 'counter for on time
if gpio.4 = on and gpio.1 = off then set gpio.2 on
wait 1 s 'should set cycle time to one Hz
if timer = 100 then 'should set on time to 100 sec.
set gpio.2 off
timer = 0
end if
end sub
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sounds hazardous. So take these comments as suggestions, rather than solutions to your problems. Most likely some iterative process, rather than one thing wrong.
Timing problem; could the fact that sub crowbar does not re-zero the timer counter.
Depending on how you are turning on the pump, is a noise spike corrupting the process? If you have an optoisolater hanging around, try that on the pump output line. Also make sure that the relay or mosfet has the schottky diode bypass. There was an Open Discussion topic related to motor noise, and I posted a link to someones checklist on reducing noise there.
I wouldn't even wait 1 sec to find out there is an overflow. Try using the "On Interrupt GPIOChange Call crowbar" command. You may need to check that GCBasic is setting the OPTION,INTEDG bit for a rising edge (or however you want). Also the overflow indicator would need to be routed to the GPIO2/INT pin.
Also, when testing a bit value, GCBasic would prefer a change to the following line:
if gpio.4 = on and gpio.1 = off then set gpio.2 on
to:
if gpio.4 on and gpio.1 off then set gpio.2 on
Let us know how you get on, or what turned out to be the solution to your problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kent, Thanks for your suggestions. I will try more stuff today. I saw similar variations when using a 16F88, so I think it is the software.
BTW, this is a toy problem. I am testing a breadboard of the chip only.
I am duplicating a controller I made in hardware for just for fun, to learn how to use GCBasic and PIC's.
FYI, The hardware runs an automatic tank filling pump for my emergency generator. The overfill sensor is set to one gallon reserve. The pump puts out one gallon per minute. The crowbar is a latch made from an IRF540 FET that shorts out the motor. If the power amp has failed that will blow the one amp fuse and shut everything down. I have yet to use it though. :) Regards, Ed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Ed, sounds like a neat idea. In a previous life, had installed a power transfer switch to run the refrigerator and a few necessities for a clients home. An exterior 220V plug was installed, and a portable generator was bought. But the re-filling of the gas tank thing had always bugged me.
Your config osc=int is interesting, because it is not specified in the chip data file. Would have thought:
#config OSC=INTRC_OSC_NOCLKOUT
GCBasic, or the assembler must handle it, because the assembly file is correct.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kent, thanks for the help so far, but I still need some more. You were right about the crowbar resetting the timer. That fixed it turning off the pump immediately.
I am still having a dickens of a time getting the timer on the pump to work right. What I need to have done is to turn the pump on as soon as the low gas signal comes on and then pump for 90 sec and then turn off. The low gas signal is only present for about 5 seconds. Can you suggest the correct way to do that?
With regards to the osc. I have tried your suggestion, but either way I get an error message form the programmer saying “ the OSCAL value should be in the form of a RETW instruction [34xx] currently [3Fxx] Do you want to change it? I have been saying no and it loads the file. I have checked the timing with the internal oscillator and it is about 90% of the correct value. The .asm file looks ok.
Thanks, Ed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ed, what programmer, editor/IDE, assembler toolchain are you using? With Pickit 2/crimson/MPASM, haven't seen that error before.
Some additional thoughts to simplify? The crowbar gpio.1 never got reset in software.
1) Main loop checks once a second for when pump needs to start.
2) Sub Pump handles continous pumping till count or overflow occurs.
'Main routine
Start:
pulseout gpio.0, 1 ms 'test cycle time
If gpio.4 on then pump 'check for low fuel
wait 1 s
goto Start
sub pump 'turns on pump for a period of time
If gpio.3 off then set gpio.1 off 'recheck overflow & reset crowbar
Do
If gpio.1 off then set gpio.2 on
wait 1 s 'should set cycle time to one Hz
If gpio.3 on then 'check overflow signal
set gpio.2 off 'turn off pump
set gpio.1 on 'set crowbar on
timer = 0
goto exitpump
end if
if timer = 100 then 'should set on time to 100 sec.
set gpio.2 off
timer = 0
goto exitpump
end if
timer = timer +1 'counter for on time
Loop
exitpump:
end sub
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kent, I am using crimson editor and a DYI K128 programmer from kitsrus.com
Your program is a step in the right direction, thanks alot.
I found that there is much more variation in time outs when using the internal osc. With a crystal it is much less, do not understand why that would be so!
Regards, Ed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kent, I finally got it to work the way I wanted, what a row to hoe!
Ther only problem left is a slight varation in time outs (10-20%)
Regards, Ed. Here is the code:
'A program to run a gas pump and to detect an overfill and crowbar the output
'this works fine
'Chip model
#chip 12F675, 4
#config osc=int
'Set the pin directions
dir gpio.4 in 'Low gas signal
dir gpio.3 in 'Overflow signal
dir gpio.1 out 'Crowbar output
dir gpio.2 out 'Pump output
dir gpio.0 out 'Test
set gpio.1 off
set gpio.2 off
timer = 0
'Main routine
Start:
pulseout gpio.0, 1 ms 'test cycle time
if gpio.3 = on then gosub crowbar
if gpio.4 = on and gpio.1 = off then gosub pump
goto Start
sub crowbar 'shuts down everything
set gpio.1 on
set gpio.2 off
timer = 0
end sub
sub pump 'turns on pump for a period of time
for timer = 0 to 100
set gpio.2 on
if gpio.3 = on then
set gpio.1 on
set gpio.2 off
timer = 0
end if
if gpio.1 = on then set gpio.2 off
wait 1 s '1 Hz cycle time
next
set gpio.2 off
timer = 0
end sub
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your code has several "If" that can do the loop longer or shorter depending on the conditions on GPIOs.
If you want absolute times, then a good choice is to use a "base time" , just with timer0+interrupts yo can create an 1 ms (for example) base-time, using counters you can grow to seconds, this time is absolute and not depending on the different conditions inside loops...
i hope my english is good enough to be understood..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There you go. Below is my investigation of the wait states for different clock mhz.
You could try it out on your 16f88, and see if their is such a large difference. Try the 8mhz and 4mhz clocks of the 16f88, and compare to the 12f675. If there is a large difference between both the 4mhz intrc clocks, then the 12f675 is likely out of calibration. My Pickit 2 programmer has a recalibration function for resetting the internal clock.
Put the program into MPLAB SIM to check the clock timing. MPLAB doesn't take into account the temperature, which will also have an effect on the internal RC osc. As you can see, the 4 mhz clock is the worst case.
12f675 set to 4mhz:
instr 1 ms:1.043 ms actual
instr 1 s: 1.034 s actual
12f675 set to 8mhz
instr 1 ms:1.016 ms actual
instr 1 s: 1.012 s actual
12f675 set to 20mhz:
instr 1 ms:1.0048 ms actual
instr 1 s: 1.0066 s actual
The work around (if required) would be to preload a TMR with a refresh value equal to your wait state, and have it interrupt on rollover; Or use a crystal like you mentioned.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kent Thanks. Those numbers are much better than what I see.
BTW, how do you select the different clock frequencies on the internal oscillator for the 12f675? I will check into the pickit 2 programmer
The code I presented above as a solution works but it is UGLY and inefficient. I will redo it into a state machine and post it latter.
I appreciate all your patients and help. As you can tell I have no prior programming experience.
Thanks again. Ed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ed, Realize the MPLAB SIM stopwatch exercise is really a back check on the compiler settings, and represent the best case scenario.
There is just one setting for the 12f675 internal osc at 4 mhz. In other devices the OSCCON register set the internal clock. GCBasic will pretty much handle the settings for you, if properly configured.
Have you tried the 16f88 at 8mhz internal osc? If that works well, then just upgrade to a 12f683, which also has an 8 mhz internal osc. That would save buying another programmer, even though the Pickit 2 has worked great for me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kent, thanks for the reply and the tip on the 12F683
How do I select the 8Mz option on the 18f88?
Also I note that it has a tune mode. How do I use that in GCBasic?
Much Thanks, Ed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have found the source of the timing variation. It is my test method. I pull the gas pin high by hand then pull it low again on my breadboard. Depending on where the wait 1-sec timer is in its cycle, the delay will vary. If I put a very short pulse in (2ms) then it consistently times out 9.408 seconds when set to 10seconds. This agrees well with the test pulse width and cycle time, which are also low by about the same amount. So the internal oscillator is a little off (the spec says 1%: this is 6%). Maybe it’s the power supply voltage?
I found that using the FOR NEXT command better for the timer than the IF statement, as you do not need to keep track of the timer state.
Also I get an error if I use “gpio.3 on” as you suggested (compiled.asm:61:Error [113] Symbol not previously defined (GPIO.41). compiled.asm:62:Error [113] Symbol not previously defined (GPIO.10).) instead of “gpio.3 = on”, which works. See the code below. Any Ideas?
BTW, this 8 pin dip would replace 2 14 pin logic chips in the hardware I made.
Well since I finally got something to work, as I wanted, I guess I can stop calling myself a virgin. Maybe a “newbe.” Much thanks for all your help. Regards, Ed.
Here is the final code:
'A program to run a gas pump and to detect an overfill and crowbar the output
'As a state machine with init, ready, pump, and crowbar states
'Chip model
#chip 12F675, 4
#config osc=int
'Set the pin directions
dir gpio.4 in 'Low gas signal
dir gpio.3 in 'Overflow signal
dir gpio.1 out 'Crowbar output
dir gpio.2 out 'Pump output
dir gpio.0 out 'Test
'name inputs
#define gas gpio.4
#define oops gpio.3
'init on power up - can transition only to ready
set gpio.1 off
set gpio.2 off
ready: 'Waiting for inputs - can transition to pump or crowbar states
pulseout gpio.0, 1 ms 'test cycle time
if oops = on then goto crowbar
if gas = on and gpio.1 = off then goto pump 'redundant safety check
wait 9 ms 'set sample rate to 100Hz
goto ready
crowbar: 'shuts down everything and never looks back
set gpio.1 on
set gpio.2 off
goto crowbar
pump: 'turns on pump for a period of time
for timer = 0 to 10 'number of 1 second intervals
gosub safety_check
set gpio.2 on 'turn pump on
if gpio.1 = on then set gpio.2 off ' redundant safety check
wait 1 s '1 Hz cycle time
next
set gpio.2 off 'turn pump off and return to ready
goto ready
sub safety_check
if gpio.3 = on then goto crowbar
end sub
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ed, you're welcome. Hope GCBasic works well for you, Hugh has done a masterful job in my opinion.
Approximately 4% of the timing error is in the compiler. Found a large rounding error in the wait_ms sub when using the 4 Mhz osc setting. Will see about getting it fixed.
Doh, GPIO.3 is the MCLR/VPP pin, so best not to use it. Rearrange your inputs and outputs accordingly.
That's weird on the "gpio.3 on" thing. No errors generated on my end, from GCBasic or MPASM, by checking for "on". Using the "=" adds unnecessary assembler in my book, when testing bit values. In the end, its whatever works for you that counts.
In the Syntax/Conditions of the help file, there is a caution on trying to compare two bit vaules with NOT, AND, OR, XOR. Haven't really checked into whether that is still the case or not.
Have a whole pile of analog chips that I thought I was gonna use. Considering that a 50 cent 10F200 could probably do your job, what's the point?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kent, I am intent on mastering GCBasic and PIC's. I think Hugh had done a great job. Thanks for the tip on GPIO.3
As I said I have little programming experience, other than lots of Excel analysis sheets. So I have a big learning curve yet to go. I am an electrical engineer, mostly analog and systems. Never got into the digital crap. It takes a lot of real estate to do anything. That why I am trying to learn PIC's. I do home projects as I am retired now. Helps keep my brain alive. I have great expectaions that PIC's will solve the controller problem for me much better than logic chips.
I am using gputils as suggested on your "getting started" page. I have downloads the MPLAB stuff but have not installed it yet. Is it worth while? -- just another big learning curve for me.
I am sure I will have a lot more questions when I get into the A2D and PWM stuff! Hope you are still here to help.
Regards, Ed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ed, I am also retired, from being a mechanical engineer turned general contractor. So no background whatsoever in digital electrictronics and programming, well there was one semester of Fortran.
If you could see some of my first posts, you would see a struggle up the learning curve also, and still learning more each day. In the end, you are miles ahead using bare PICS, and programming them as you please.
MPLAB I think is an acquired taste, and personally have barely scratched the surface. Haven't even tried the debugger feature that a lot of folks swear by. Using the simulator has helped me a couple of times, in determining if a register value gets set, endless loops or sticking points, and of course the stopwatch function. It seems to me that sprinkling led flashes around, or hooking up an LCD can tell me just as much. MPLAB is worth a look when your programs become more complex or when time permits, and certainly not mandatory.
Some people do crossword puzzles, some people do PIC puzzles! Have to keep the gray matter exercised.
And recently, there seems to be some very experienced PIC users out there. The more voices chiming in on the forum, the better to keep us all in line.
Regards,
Kent
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kent, thanks for your reply. You are right about the gray matter! I recently designed the servo system for a friend of mine who plans to get into the robot business. You can see it here: http://www.eliteeng.com/RoboticsIntroduction.htm.
He worked for me for many years at 3 of the companies I started. Hired him right out of school. He is a digital and part time analog and mechanical engineer and is real smart. He did not do much servo control stuff so I volunteered to do it for free. I used to do this stuff all day long and even in my sleep. After being retired for 8 years my mind had became vapor locked. I sat down to derive the transfer functions of the loop; I would get to the end of the page and forget what I was trying to do! It took me a week to do what I could do in 30 minutes in my prime. After that experience I decided to keep my mind working HARD. So I have been doing more projects aimed at making me THINK, hence the PIC effort. Plus it will be a useful skill when I get there.
Also, in my haste to get going on the PIC stuff, I failed to notice the oscillator calibrate function in the programmer. I probably will look at MPLAB when the dust settle a little.
Are you a moderator on this forum (I see a wrench next to your name) or just an active user?
Regards, Ed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That gripper arm looks very interesting, and of industrial quality, cool.
Yes, the (surprise) moderator privileges, due mostly to my persistence on the forum, during the leaner times. If I can help people out new to GCBasic, or suggest a way to use GCBasics functionality, that's a good thing. Although occasionally can suggest fixes to bugs in header files, don't really mess with the compiler code (FreeBasic).
When you run out of things to do on the Pic, you can try the AVR, haha, it never ends.
;Undocumented Atmel code (alpha stage functionality)
#chip mega168,8
dir PortB.0 out
dir PortB.1 out
start:
set PortB.0 on
set PortB.1 off
waitsec
set PortB.0 off
set PortB.1 on
waitsec
goto start
;compiler bug when using seconds for AVR
Sub waitsec
for runloop = 1 to 4
wait 250 ms
next
end sub
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all, it’s the PIC virgin again. I have a simple program to turn on a pump for 100 seconds. The measured on time is variable from about 60 sec. to about 80 seconds. I do not understand why it is not 100 sec. and varies from each time it is activated.
The measured cycle time is about 1 Hz as it should be.
Also the crowbar should not have more than a 1 sec delay, however it does not function until the timer has timed out and the pump is shut off!. Can anyone help out? Regards, Ed.
'A program to run a gas pump and to detect an overfill and crowbar the output
'Chip model
#chip 12F675, 4
#config osc=int
'Set the pin directions
dir gpio.4 in 'Low gas signal
dir gpio.3 in 'Overflow signal
dir gpio.1 out 'Crowbar output
dir gpio.2 out 'Pump output
dir gpio.0 out 'Test point
'initialize outputs and timer
set gpio.1 off
set gpio.2 off
timer = 0
'Main routine
Start:
pulseout gpio.0, 1 ms 'test cycle time
gosub crowbar
gosub pump
goto Start
sub crowbar 'shuts down everything
if gpio.3 = on then set gpio.1 on
end sub
sub pump 'turns on pump for a period of time
timer = timer +1 'counter for on time
if gpio.4 = on and gpio.1 = off then set gpio.2 on
wait 1 s 'should set cycle time to one Hz
if timer = 100 then 'should set on time to 100 sec.
set gpio.2 off
timer = 0
end if
end sub
Sounds hazardous. So take these comments as suggestions, rather than solutions to your problems. Most likely some iterative process, rather than one thing wrong.
Timing problem; could the fact that sub crowbar does not re-zero the timer counter.
Depending on how you are turning on the pump, is a noise spike corrupting the process? If you have an optoisolater hanging around, try that on the pump output line. Also make sure that the relay or mosfet has the schottky diode bypass. There was an Open Discussion topic related to motor noise, and I posted a link to someones checklist on reducing noise there.
I wouldn't even wait 1 sec to find out there is an overflow. Try using the "On Interrupt GPIOChange Call crowbar" command. You may need to check that GCBasic is setting the OPTION,INTEDG bit for a rising edge (or however you want). Also the overflow indicator would need to be routed to the GPIO2/INT pin.
Also, when testing a bit value, GCBasic would prefer a change to the following line:
if gpio.4 = on and gpio.1 = off then set gpio.2 on
to:
if gpio.4 on and gpio.1 off then set gpio.2 on
Let us know how you get on, or what turned out to be the solution to your problem.
Kent, Thanks for your suggestions. I will try more stuff today. I saw similar variations when using a 16F88, so I think it is the software.
BTW, this is a toy problem. I am testing a breadboard of the chip only.
I am duplicating a controller I made in hardware for just for fun, to learn how to use GCBasic and PIC's.
FYI, The hardware runs an automatic tank filling pump for my emergency generator. The overfill sensor is set to one gallon reserve. The pump puts out one gallon per minute. The crowbar is a latch made from an IRF540 FET that shorts out the motor. If the power amp has failed that will blow the one amp fuse and shut everything down. I have yet to use it though. :) Regards, Ed.
Hi Ed, sounds like a neat idea. In a previous life, had installed a power transfer switch to run the refrigerator and a few necessities for a clients home. An exterior 220V plug was installed, and a portable generator was bought. But the re-filling of the gas tank thing had always bugged me.
Your config osc=int is interesting, because it is not specified in the chip data file. Would have thought:
#config OSC=INTRC_OSC_NOCLKOUT
GCBasic, or the assembler must handle it, because the assembly file is correct.
Kent, thanks for the help so far, but I still need some more. You were right about the crowbar resetting the timer. That fixed it turning off the pump immediately.
I am still having a dickens of a time getting the timer on the pump to work right. What I need to have done is to turn the pump on as soon as the low gas signal comes on and then pump for 90 sec and then turn off. The low gas signal is only present for about 5 seconds. Can you suggest the correct way to do that?
With regards to the osc. I have tried your suggestion, but either way I get an error message form the programmer saying “ the OSCAL value should be in the form of a RETW instruction [34xx] currently [3Fxx] Do you want to change it? I have been saying no and it loads the file. I have checked the timing with the internal oscillator and it is about 90% of the correct value. The .asm file looks ok.
Thanks, Ed.
Ed, what programmer, editor/IDE, assembler toolchain are you using? With Pickit 2/crimson/MPASM, haven't seen that error before.
Some additional thoughts to simplify? The crowbar gpio.1 never got reset in software.
1) Main loop checks once a second for when pump needs to start.
2) Sub Pump handles continous pumping till count or overflow occurs.
'Main routine
Start:
pulseout gpio.0, 1 ms 'test cycle time
If gpio.4 on then pump 'check for low fuel
wait 1 s
goto Start
sub pump 'turns on pump for a period of time
If gpio.3 off then set gpio.1 off 'recheck overflow & reset crowbar
Do
If gpio.1 off then set gpio.2 on
wait 1 s 'should set cycle time to one Hz
If gpio.3 on then 'check overflow signal
set gpio.2 off 'turn off pump
set gpio.1 on 'set crowbar on
timer = 0
goto exitpump
end if
if timer = 100 then 'should set on time to 100 sec.
set gpio.2 off
timer = 0
goto exitpump
end if
timer = timer +1 'counter for on time
Loop
exitpump:
end sub
Kent, I am using crimson editor and a DYI K128 programmer from kitsrus.com
Your program is a step in the right direction, thanks alot.
I found that there is much more variation in time outs when using the internal osc. With a crystal it is much less, do not understand why that would be so!
Regards, Ed.
Kent, I finally got it to work the way I wanted, what a row to hoe!
Ther only problem left is a slight varation in time outs (10-20%)
Regards, Ed. Here is the code:
'A program to run a gas pump and to detect an overfill and crowbar the output
'this works fine
'Chip model
#chip 12F675, 4
#config osc=int
'Set the pin directions
dir gpio.4 in 'Low gas signal
dir gpio.3 in 'Overflow signal
dir gpio.1 out 'Crowbar output
dir gpio.2 out 'Pump output
dir gpio.0 out 'Test
set gpio.1 off
set gpio.2 off
timer = 0
'Main routine
Start:
pulseout gpio.0, 1 ms 'test cycle time
if gpio.3 = on then gosub crowbar
if gpio.4 = on and gpio.1 = off then gosub pump
goto Start
sub crowbar 'shuts down everything
set gpio.1 on
set gpio.2 off
timer = 0
end sub
sub pump 'turns on pump for a period of time
for timer = 0 to 100
set gpio.2 on
if gpio.3 = on then
set gpio.1 on
set gpio.2 off
timer = 0
end if
if gpio.1 = on then set gpio.2 off
wait 1 s '1 Hz cycle time
next
set gpio.2 off
timer = 0
end sub
Hello...
Your code has several "If" that can do the loop longer or shorter depending on the conditions on GPIOs.
If you want absolute times, then a good choice is to use a "base time" , just with timer0+interrupts yo can create an 1 ms (for example) base-time, using counters you can grow to seconds, this time is absolute and not depending on the different conditions inside loops...
i hope my english is good enough to be understood..
There you go. Below is my investigation of the wait states for different clock mhz.
You could try it out on your 16f88, and see if their is such a large difference. Try the 8mhz and 4mhz clocks of the 16f88, and compare to the 12f675. If there is a large difference between both the 4mhz intrc clocks, then the 12f675 is likely out of calibration. My Pickit 2 programmer has a recalibration function for resetting the internal clock.
Put the program into MPLAB SIM to check the clock timing. MPLAB doesn't take into account the temperature, which will also have an effect on the internal RC osc. As you can see, the 4 mhz clock is the worst case.
12f675 set to 4mhz:
instr 1 ms:1.043 ms actual
instr 1 s: 1.034 s actual
12f675 set to 8mhz
instr 1 ms:1.016 ms actual
instr 1 s: 1.012 s actual
12f675 set to 20mhz:
instr 1 ms:1.0048 ms actual
instr 1 s: 1.0066 s actual
The work around (if required) would be to preload a TMR with a refresh value equal to your wait state, and have it interrupt on rollover; Or use a crystal like you mentioned.
Kent Thanks. Those numbers are much better than what I see.
BTW, how do you select the different clock frequencies on the internal oscillator for the 12f675? I will check into the pickit 2 programmer
The code I presented above as a solution works but it is UGLY and inefficient. I will redo it into a state machine and post it latter.
I appreciate all your patients and help. As you can tell I have no prior programming experience.
Thanks again. Ed.
Ed, Realize the MPLAB SIM stopwatch exercise is really a back check on the compiler settings, and represent the best case scenario.
There is just one setting for the 12f675 internal osc at 4 mhz. In other devices the OSCCON register set the internal clock. GCBasic will pretty much handle the settings for you, if properly configured.
Have you tried the 16f88 at 8mhz internal osc? If that works well, then just upgrade to a 12f683, which also has an 8 mhz internal osc. That would save buying another programmer, even though the Pickit 2 has worked great for me.
Kent, thanks for the reply and the tip on the 12F683
How do I select the 8Mz option on the 18f88?
Also I note that it has a tune mode. How do I use that in GCBasic?
Much Thanks, Ed.
Recent post on internal osc https://sourceforge.net/forum/forum.php?thread_id=2975827&forum_id=579126
Never have used osctune, but if you were going to mess with it, then it would be on the order of osctune = b'xxxxx'
Kent Thanks alot.
I have found the source of the timing variation. It is my test method. I pull the gas pin high by hand then pull it low again on my breadboard. Depending on where the wait 1-sec timer is in its cycle, the delay will vary. If I put a very short pulse in (2ms) then it consistently times out 9.408 seconds when set to 10seconds. This agrees well with the test pulse width and cycle time, which are also low by about the same amount. So the internal oscillator is a little off (the spec says 1%: this is 6%). Maybe it’s the power supply voltage?
I found that using the FOR NEXT command better for the timer than the IF statement, as you do not need to keep track of the timer state.
Also I get an error if I use “gpio.3 on” as you suggested (compiled.asm:61:Error [113] Symbol not previously defined (GPIO.41). compiled.asm:62:Error [113] Symbol not previously defined (GPIO.10).) instead of “gpio.3 = on”, which works. See the code below. Any Ideas?
BTW, this 8 pin dip would replace 2 14 pin logic chips in the hardware I made.
Well since I finally got something to work, as I wanted, I guess I can stop calling myself a virgin. Maybe a “newbe.” Much thanks for all your help. Regards, Ed.
Here is the final code:
'A program to run a gas pump and to detect an overfill and crowbar the output
'As a state machine with init, ready, pump, and crowbar states
'Chip model
#chip 12F675, 4
#config osc=int
'Set the pin directions
dir gpio.4 in 'Low gas signal
dir gpio.3 in 'Overflow signal
dir gpio.1 out 'Crowbar output
dir gpio.2 out 'Pump output
dir gpio.0 out 'Test
'name inputs
#define gas gpio.4
#define oops gpio.3
'init on power up - can transition only to ready
set gpio.1 off
set gpio.2 off
ready: 'Waiting for inputs - can transition to pump or crowbar states
pulseout gpio.0, 1 ms 'test cycle time
if oops = on then goto crowbar
if gas = on and gpio.1 = off then goto pump 'redundant safety check
wait 9 ms 'set sample rate to 100Hz
goto ready
crowbar: 'shuts down everything and never looks back
set gpio.1 on
set gpio.2 off
goto crowbar
pump: 'turns on pump for a period of time
for timer = 0 to 10 'number of 1 second intervals
gosub safety_check
set gpio.2 on 'turn pump on
if gpio.1 = on then set gpio.2 off ' redundant safety check
wait 1 s '1 Hz cycle time
next
set gpio.2 off 'turn pump off and return to ready
goto ready
sub safety_check
if gpio.3 = on then goto crowbar
end sub
Ed, you're welcome. Hope GCBasic works well for you, Hugh has done a masterful job in my opinion.
Approximately 4% of the timing error is in the compiler. Found a large rounding error in the wait_ms sub when using the 4 Mhz osc setting. Will see about getting it fixed.
Doh, GPIO.3 is the MCLR/VPP pin, so best not to use it. Rearrange your inputs and outputs accordingly.
That's weird on the "gpio.3 on" thing. No errors generated on my end, from GCBasic or MPASM, by checking for "on". Using the "=" adds unnecessary assembler in my book, when testing bit values. In the end, its whatever works for you that counts.
In the Syntax/Conditions of the help file, there is a caution on trying to compare two bit vaules with NOT, AND, OR, XOR. Haven't really checked into whether that is still the case or not.
Have a whole pile of analog chips that I thought I was gonna use. Considering that a 50 cent 10F200 could probably do your job, what's the point?
Kent, I am intent on mastering GCBasic and PIC's. I think Hugh had done a great job. Thanks for the tip on GPIO.3
As I said I have little programming experience, other than lots of Excel analysis sheets. So I have a big learning curve yet to go. I am an electrical engineer, mostly analog and systems. Never got into the digital crap. It takes a lot of real estate to do anything. That why I am trying to learn PIC's. I do home projects as I am retired now. Helps keep my brain alive. I have great expectaions that PIC's will solve the controller problem for me much better than logic chips.
I am using gputils as suggested on your "getting started" page. I have downloads the MPLAB stuff but have not installed it yet. Is it worth while? -- just another big learning curve for me.
I am sure I will have a lot more questions when I get into the A2D and PWM stuff! Hope you are still here to help.
Regards, Ed.
Ed, I am also retired, from being a mechanical engineer turned general contractor. So no background whatsoever in digital electrictronics and programming, well there was one semester of Fortran.
If you could see some of my first posts, you would see a struggle up the learning curve also, and still learning more each day. In the end, you are miles ahead using bare PICS, and programming them as you please.
MPLAB I think is an acquired taste, and personally have barely scratched the surface. Haven't even tried the debugger feature that a lot of folks swear by. Using the simulator has helped me a couple of times, in determining if a register value gets set, endless loops or sticking points, and of course the stopwatch function. It seems to me that sprinkling led flashes around, or hooking up an LCD can tell me just as much. MPLAB is worth a look when your programs become more complex or when time permits, and certainly not mandatory.
Some people do crossword puzzles, some people do PIC puzzles! Have to keep the gray matter exercised.
And recently, there seems to be some very experienced PIC users out there. The more voices chiming in on the forum, the better to keep us all in line.
Regards,
Kent
Kent, thanks for your reply. You are right about the gray matter! I recently designed the servo system for a friend of mine who plans to get into the robot business. You can see it here: http://www.eliteeng.com/RoboticsIntroduction.htm.
He worked for me for many years at 3 of the companies I started. Hired him right out of school. He is a digital and part time analog and mechanical engineer and is real smart. He did not do much servo control stuff so I volunteered to do it for free. I used to do this stuff all day long and even in my sleep. After being retired for 8 years my mind had became vapor locked. I sat down to derive the transfer functions of the loop; I would get to the end of the page and forget what I was trying to do! It took me a week to do what I could do in 30 minutes in my prime. After that experience I decided to keep my mind working HARD. So I have been doing more projects aimed at making me THINK, hence the PIC effort. Plus it will be a useful skill when I get there.
Also, in my haste to get going on the PIC stuff, I failed to notice the oscillator calibrate function in the programmer. I probably will look at MPLAB when the dust settle a little.
Are you a moderator on this forum (I see a wrench next to your name) or just an active user?
Regards, Ed.
That gripper arm looks very interesting, and of industrial quality, cool.
Yes, the (surprise) moderator privileges, due mostly to my persistence on the forum, during the leaner times. If I can help people out new to GCBasic, or suggest a way to use GCBasics functionality, that's a good thing. Although occasionally can suggest fixes to bugs in header files, don't really mess with the compiler code (FreeBasic).
When you run out of things to do on the Pic, you can try the AVR, haha, it never ends.
;Undocumented Atmel code (alpha stage functionality)
#chip mega168,8
dir PortB.0 out
dir PortB.1 out
start:
set PortB.0 on
set PortB.1 off
waitsec
set PortB.0 off
set PortB.1 on
waitsec
goto start
;compiler bug when using seconds for AVR
Sub waitsec
for runloop = 1 to 4
wait 250 ms
next
end sub
Kent, Thanks. At my rate of learning PIC I will be dead before I run out of things to do.
Thanks again for all your help. regards, Ed.