Does Count tie up the program?
- Thread starter cloudy
- Start date
Yes (ties up the program) and no (interrupts won't be acted upon during the count)
...see the SETINT command in Manual 2...
[interrupts are checked for ]between execution of each command line in the program, between each note of a tune command, and continuously during any pause command
...see the SETINT command in Manual 2...
[interrupts are checked for ]between execution of each command line in the program, between each note of a tune command, and continuously during any pause command
Damn, the simulator wasn't showing that - I had thought perhaps that was going to be an issue. Is my only option is a freq>voltage IC and then ADC input that to avoid tying up the CPU? I'm measuring engine RPM, whilst listening for a button press - the decision on whether to act on the button press is based on the last RPM variable. The button press could occur at any time and must be acted on instantly...
James
James
hippy
Ex-Staff (retired)
As MartinM57 says.
If you want interrupt responses, or just faster execution, you may be able to sample for less time and adjust the value counted. For example if your count is 9900 over 1 second, you could count for half a second, get 4950, and double that to get back to 9900.
You'll have to tell us what you are trying to achieve to get best responses and alternatives to a problem.
If you want interrupt responses, or just faster execution, you may be able to sample for less time and adjust the value counted. For example if your count is 9900 over 1 second, you could count for half a second, get 4950, and double that to get back to 9900.
You'll have to tell us what you are trying to achieve to get best responses and alternatives to a problem.
Probably depends on:
- what engine rpm - can you COUNT for less than a second and still get accurate and sufficient resolution rpm?
- how quick is "instant" - bearing in mind you'll be highly unlikely to come up with any software based solution that works "instantly"
- what PICAXE you are using (always good to indicate) - some chips have a background hardware counting ability that might be suitable
- what engine rpm - can you COUNT for less than a second and still get accurate and sufficient resolution rpm?
- how quick is "instant" - bearing in mind you'll be highly unlikely to come up with any software based solution that works "instantly"
- what PICAXE you are using (always good to indicate) - some chips have a background hardware counting ability that might be suitable
Just replied above, it's a good idea, but the minimum I can sample for is 100ms for an accurate enough rpm, but the button push action is firing an output for just 60ms within 7ms (this portion tested and working) so it has to pick up the interrupt near to instantly...
Chip is an 18X
Chip is an 18X
...and/or:
- how you are measuring rpm - you could use PULSIN to measure the duration of one tooth (or whatever) - goes to sub-microsecond accuracy at high SETFREQs - and calculate rpm from that
Background counting - see SETTIMER COUNT command in Manual 2 EDIT: not for 18X though - but it gives a reason to send off for some new PICAXEs
- how you are measuring rpm - you could use PULSIN to measure the duration of one tooth (or whatever) - goes to sub-microsecond accuracy at high SETFREQs - and calculate rpm from that
Background counting - see SETTIMER COUNT command in Manual 2 EDIT: not for 18X though - but it gives a reason to send off for some new PICAXEs
Very true!, though I've been using it for 2 years, just decided to add some features...
I've read this in the manual - which confuses matters even more!
However this system can cause potential issues on timing sensitive commands
such as those using serial or one-wire communication. If the event were to occur
during the timing sensitive command, the command would become corrupt as
the timing would be altered and hence incorrect data would be sent in/out of the
PICAXE chips. Therefore the following commands must temporarily disable all
interrupts whilst processing:
Serial: serin, serout, serrxd, sertxd, debug
One-wire: owin, owout, readtemp, readtemp12, readowsn
UNI/O: uniin, uniout
Infra-red: infraout, irout
Note that other timing commands (e.g. count, pulsin, pulsout etc.) do not
disable the interrupts, but, if active, the hardware interrupt processing time may
affect the accuracy of these commands when they are processed.
Any comment?
I've read this in the manual - which confuses matters even more!
However this system can cause potential issues on timing sensitive commands
such as those using serial or one-wire communication. If the event were to occur
during the timing sensitive command, the command would become corrupt as
the timing would be altered and hence incorrect data would be sent in/out of the
PICAXE chips. Therefore the following commands must temporarily disable all
interrupts whilst processing:
Serial: serin, serout, serrxd, sertxd, debug
One-wire: owin, owout, readtemp, readtemp12, readowsn
UNI/O: uniin, uniout
Infra-red: infraout, irout
Note that other timing commands (e.g. count, pulsin, pulsout etc.) do not
disable the interrupts, but, if active, the hardware interrupt processing time may
affect the accuracy of these commands when they are processed.
Any comment?
You are confusing firmware internal timer interrupts (e.g. to drive a background servo pulse) with the setint command for a 'user' interrupt.
The firmware will keep going (ie servo pulses keep going) but the user external interrupt won't activate until the count command has completed.
The firmware will keep going (ie servo pulses keep going) but the user external interrupt won't activate until the count command has completed.