28X2 not running 18X program
- Thread starter jglenn
- Start date
westaust55
Moderator
@jglenn,
Can I suggest that you have a look at my PICAXE memory map and SFR data available here:
http://www.picaxeforum.co.uk/showthread.php?t=11514
You can see how the bits, byte variables and word variables overlap and a lot more.
Very good, not only reading, but printing out your ref. The X2 are greatly expanded, the extra features have not been absorbed yet.
One thing lurking in the shadows is a watchdog, I may stick a socket on my board for an 8 pin pic, to tickle the reset line every once in awhile,
if, in the field, crashing occurs. A bit of planning is better than hot melt glue and a bunch of wirewrap wires.
One thing lurking in the shadows is a watchdog, I may stick a socket on my board for an 8 pin pic, to tickle the reset line every once in awhile,
if, in the field, crashing occurs. A bit of planning is better than hot melt glue and a bunch of wirewrap wires.
hippy
Ex-Staff (retired)
The 20X2's don't have a hardware watchdog capability exposed at the PICAXE programming level but there are multiple ways to do that -
* Use SETTIMER
* Use an external interrupt to an INT pin
* Use an external Reset
The last is most reliable because it will guarantee a restart of the PICAXE program and won't fail if the PICAXE itself has failed somehow.
It does rely on the watchdog itself having not failed. If you use a PICAXE as a watchdog, then how do you know something causing a failure of the main PICAXE won't also cause a failure of the watchdog PICAXE ? The better watchdogs are those which are purely hardware based and have a greater immunity to failure than what they are watching over.
* Use SETTIMER
* Use an external interrupt to an INT pin
* Use an external Reset
The last is most reliable because it will guarantee a restart of the PICAXE program and won't fail if the PICAXE itself has failed somehow.
It does rely on the watchdog itself having not failed. If you use a PICAXE as a watchdog, then how do you know something causing a failure of the main PICAXE won't also cause a failure of the watchdog PICAXE ? The better watchdogs are those which are purely hardware based and have a greater immunity to failure than what they are watching over.
Hippy, your code works great, kudos. I am not so worried about the watchdog, just planned on using a 10K pullup R on the reset line, with a socket for a raw PIC12C508, assy prog., that would do a brute force toggle for 50mS on the reset line every 30 sec, if there are field reports of crashing. I know good watchdogs work better, but if necessary I'd send them the chip.
A couple other questions. When I use the 28X2 in a target application, I know I must ground the serial in line, p6. What are all the unused input pins on this chip? I know so far to ground pins 2-6, 8, and 19. Some of the other pins look like mostly outputs, but some can be config as inputs, what is the boot default?
My scheme of counting 60 Hz pulses over 4 sec produces a value of 240, which is output by the D/A, about 4.6 volts, which is divided by 4 with a resistor voltage divider, a 1K pot. Plan on 1% res and a 100 ohm trimpot to set it. 60.0 Hz = 0.600V to the meter.
But the problem is that I cannot read above 61.8 Hz, it just sticks at that until greater than 65Hz, where it rolls over and starts from zero again. This
is not a big problem, as they are always reading 60 HZ +\-1, but I want to
make it stick at 62Hz if it goes higher. Have to update schematic of this 5 meter board for the layout guy right now (3 amps, 1 volts, 1 freq), any suggestions on limiter statements are welcome!
A couple other questions. When I use the 28X2 in a target application, I know I must ground the serial in line, p6. What are all the unused input pins on this chip? I know so far to ground pins 2-6, 8, and 19. Some of the other pins look like mostly outputs, but some can be config as inputs, what is the boot default?
My scheme of counting 60 Hz pulses over 4 sec produces a value of 240, which is output by the D/A, about 4.6 volts, which is divided by 4 with a resistor voltage divider, a 1K pot. Plan on 1% res and a 100 ohm trimpot to set it. 60.0 Hz = 0.600V to the meter.
But the problem is that I cannot read above 61.8 Hz, it just sticks at that until greater than 65Hz, where it rolls over and starts from zero again. This
is not a big problem, as they are always reading 60 HZ +\-1, but I want to
make it stick at 62Hz if it goes higher. Have to update schematic of this 5 meter board for the layout guy right now (3 amps, 1 volts, 1 freq), any suggestions on limiter statements are welcome!
Code:
main: i2cslave %00011000,i2cslow_16,i2cbyte 'config i2c
setfreq em16
main2: Count C.7, 16000, w2
w2 = w2 << 4
WriteI2c 0, ( %00011000, b5, b4 )
goto main2
Last edited:
hippy
Ex-Staff (retired)
COUNT should be giving the correct result so I'd suggest putting a SERTXD or DEBUG in there to see what result you are reading.
The issue may be that your DAC only works in steps of 16. Once you know what COUNT is reading you'll be able to see how well the DAC matches the counted value.
You can remove the COUNT, replace it with a constant assignment or FOR-NEXT and output specific values and check the DAC / meter result matches what the value is.
COUNT cannot count half pulses so it will tend to lose those. The alternative is to use PULSIN, measure the length of the pulse, calculate the frequency / DAC value from that.
The issue may be that your DAC only works in steps of 16. Once you know what COUNT is reading you'll be able to see how well the DAC matches the counted value.
You can remove the COUNT, replace it with a constant assignment or FOR-NEXT and output specific values and check the DAC / meter result matches what the value is.
COUNT cannot count half pulses so it will tend to lose those. The alternative is to use PULSIN, measure the length of the pulse, calculate the frequency / DAC value from that.
I guess I was not clear. Count is working fine, and the accuracy is right on,
I am using a 4 MHz xtal, and have a meter from work that reads 0.001 Hz,
just need to track it from 50 Hz to about 62Hz. Generators shut off anyway
on overspeed at about 65Hz.
I am using count over 4 seconds to get more resolution, since the meters read .1Hz, should be using 10 sec, but that is too long a wait for update.
A count of 240 is 60.0 Hz. But when I feed my program more than 62 Hz,
it overranges, and the display "rolls over" to zero. All I wanted to do is limit
the readout to 62 Hz, that is, "jam" a value of 62 in, if the real world tries to give it a higher value. Like this, seems to work. Next part is to get it to read 60.0 Hz even
when there is jitter causing it to jump around a little. It is pretty stable, I put
a 1 uF film cap across the meter input, but these guys are fanatical, they want it to read 60.0 Hz most the time, the computer panel this goes with does that
(and I happen to know they use bracketing tricks like this).
Maybe there is a more elegant way to introduce the 62Hz limiting, this
is cumbersome.
I am using a 4 MHz xtal, and have a meter from work that reads 0.001 Hz,
just need to track it from 50 Hz to about 62Hz. Generators shut off anyway
on overspeed at about 65Hz.
I am using count over 4 seconds to get more resolution, since the meters read .1Hz, should be using 10 sec, but that is too long a wait for update.
A count of 240 is 60.0 Hz. But when I feed my program more than 62 Hz,
it overranges, and the display "rolls over" to zero. All I wanted to do is limit
the readout to 62 Hz, that is, "jam" a value of 62 in, if the real world tries to give it a higher value. Like this, seems to work. Next part is to get it to read 60.0 Hz even
when there is jitter causing it to jump around a little. It is pretty stable, I put
a 1 uF film cap across the meter input, but these guys are fanatical, they want it to read 60.0 Hz most the time, the computer panel this goes with does that
(and I happen to know they use bracketing tricks like this).
Maybe there is a more elegant way to introduce the 62Hz limiting, this
is cumbersome.
Code:
main: i2cslave %00011000,i2cslow_16,i2cbyte 'config i2c
setfreq em16
main2: Count C.7, 16000, w2
if w2 > 248 then main4 'if HZ > 62 then
main3: w2 = w2 << 4
WriteI2c 0, ( %00011000, b5, b4 )
debug
goto main2
main4: w2 = 248 'limit to 62
goto main3
Last edited:
lbenson
Senior Member
No difference in execution, but I would tend to write it thus:
The jumps to different labels are more like assembly language programming than a structured higher-level language.
Code:
i2cslave %00011000,i2cslow_16,i2cbyte 'config i2c
setfreq em16
main:
do
Count C.7, 16000, w2
if w2 > 248 then 'if HZ > 62 then
w2 = 248 'limit to 62
endif
w2 = w2 << 4
WriteI2c 0, ( %00011000, b5, b4 )
debug
loop
Last edited:
Cool, I was trying to figure out how to do it that way. Yes that was spagetti code technique, in assembly I try to use mostly subroutines, and just call them up. Will use your method to bracket the 60.0 reading to eliminate drift
tomorrow. Midnite engineering on this project.
tomorrow. Midnite engineering on this project.
Alright, another new command (to me)! Incorporated, along with bensons
sugg, and added needed "bracketing". For this job I need it to read 60.0 Hz
even if the count is +\-2 varying from that. This seems to work. Not worried
about simplif, but will listen to improvements.
sugg, and added needed "bracketing". For this job I need it to read 60.0 Hz
even if the count is +\-2 varying from that. This seems to work. Not worried
about simplif, but will listen to improvements.
Code:
'HZ converter 2010.1
i2cslave %00011000,i2cslow_16,i2cbyte 'config i2c
setfreq em16
main:
do
Count C.7, 16000, w2
if w2 = 238 then
w2 = 240
endif
if w2 = 239 then 'bracket for 60.0 HZ
w2 = 240
endif
if w2 = 241 then
w2 = 240
endif
if w2 = 242 then
w2 = 240
endif
w2 = w2 Max 248 << 4 'limit to 62
WriteI2c 0, ( %00011000, b5, b4 )
loopYes. It may be "cheating", but understanding what the customer expects
often overrides everything else, this guy will complain if the weather is bad
when he gets the shipment. Our engine controller does something close with
3 phase AC voltage readings. When it is close to 208V, it will read 208V.
I am happy with the PICAXE solution. It would have been nice to use the xtal
on a cheaper chip, but now I have some for better projects. One thing I'd love
to have is the 28 pin proto board with a real machined pin socket for the chip.
Those leaf spring things are not the best. Any chance of a few blank boards?
often overrides everything else, this guy will complain if the weather is bad
when he gets the shipment. Our engine controller does something close with
3 phase AC voltage readings. When it is close to 208V, it will read 208V.
I am happy with the PICAXE solution. It would have been nice to use the xtal
on a cheaper chip, but now I have some for better projects. One thing I'd love
to have is the 28 pin proto board with a real machined pin socket for the chip.
Those leaf spring things are not the best. Any chance of a few blank boards?