Definitely not a hardware question IMO. Minimum pulse width that can be detected is determined by clock speed, firmware polling rate and your code.
Consider the following code:
Code:
#Picaxe 08M2
#no_data
setint %00001000,%00001000 '// int on Pinc.3 high
do
pause 1000 ' waiting for interrupt
loop
interrupt:
pulsout 2000,C.1 '//LED on Pin C.1 for testing
setint %00001000,%00001000
return
The program above can reliably detect pulses of 80 us in duration with the Processor clock @ M4. However with the clock @M32 it can reliably detect pulses of 10us in duration. These are 'about' the hardware/ firmware limits as I am not motivated to test to the exact microsecond.
Your code , especially the omitted numdisplay subroutine along with the slow 4MHZ clock in the main sub are the primary reasons that a "pulse stretcher" is needed. Also the interrupt routine is rather bloated. The interrupt routine should be as short as practical. ie increment a variable , set a flag, ... and then move on.
OK. Thanks.
I DID try increasing the clock speed, but to no avail.
Re bloated interrupt routine...
As I have posted, I don't mind missing the occasional pulse that might arrive during the interrupt routine. That will introduce a bit of a systematic proportional and predictable error (which I can live with). My problem was the interrupt routine was not getting called at all.
I was hoping this project would do something practical clever and useful. I can't achieve anything useful with the constraints that the interrupt routine has to be 'light' as WELL as the main code that is interrupted! That would make any PicAxe lover weep.
I appreciate specific blocking commands might stop an interrupt call e.g. Nap and going to sleep but hope I have avoided these and the code is quite varied to my eyes. You would surely say the "the omitted numdisplay subroutine" is very bloated too BUT logically it can be interrupted and it just contains a variety of normal, if long and bloated, maths and conditional basic commands. There are lots of pauses too. Please, can you help me by saying what
quality in it might stop it from allowing ANY interrupt calls to be generated because that is what would be very helpful to me and others.
I have not posted the entire code here because...
I have written and tested the logic so it can be EITHER a pulse counter, OR an up or down timer, OR a scalable rate meter (free running or one shot), just depending on flags that are set and what I want at the time. That I know would confuse anyone! Besides, I have that all that bit tested tuned tweaked and working. That bit works before the sensor is attached and with the pulse stretcher in place.
"Syntax check successful!
Memory used = 1414 bytes out of 2048"
Yes it is long and you might say bloated but I thought that should not in itself stop it from being interrupted.
The problem is that, I feared and then found, the interrupt routine was just not being called at all by my input pulses which were just not noticed at all till I stretched them. They are described as 'TTL' full voltage pulses so I thought they should have been picked up in terms of voltage rise and impedance (but I admit I am out of my depth here). I could easily see them just with an LED (I do realise a phosphor will extend the pulse as will POV), and taking away the LED to stop voltage being clipped did not help. A transistor buffer did not help either.
If you have tested your measurements above, what happens if you put more varied 'work' e.g. maths and conditional branches into the main program, rather than just pure pauses? If it reliably detects narrow pulses of the width I'm working with then there is indeed a simple answer to the original question. HertzHog
HertzHog