Interrupt time and freq

[ol boy]

Here is my interrupt routine to measure the input pulses from a vehicle speed sensor. How long does this routine take to process? At 65 mph it receives 65 pulses in 0.350 seconds. At what input frequency does it begin to miss input pulses?

interrupt: if toflag = 1 then			'check if interrupt was caused by toflag. 	settimer off			'turn off timer 	mph = w15				'load w15 to MPH 	let w15 = 0				'clear w15 value to zero 	let toflag = 0 			'clear over flow flag 	 elseif w15 = 0 then			'on first hardware input w15 will still be zero 	inc w15				'increment w15 	let hint1flag = 0	 		'clear hardware flag 	let timer = 65535			'preloads timer to overflow and set toflag when minor ticks finish counting 	settimer 54535			'enable timer 0.352 seconds else 	inc w15				'increment w15 	let hint1flag = 0	 		'clear hardware flag endif setintflags or %10000010, %10000010 'hardware interrupt INT1, Timer over flow flag	 return

 

[Goeytex]

And now the dreaded "Inquisition"

1. Is this code part of the same program for reading the 208 bytes of serial data? Or will it be on a different Picaxe microcontroller?
2. Is this to measure relative speed or for a speedometer output/display?
3. Do you need real time speed measurement/display or can the result/display substantially lag the actual speed by say 1/2 second?
4. Where is the rest of the code ? Partial code can be confusing to those without crystal balls
5. Are the pulses fixed width with variable off time, or do the pulse width and off time both change with speed?
6. The time for routine to process the code when counting pulses depends upon the pulse rate / not the processor
7. The processing overhead depends upon the commands and the processor speed. What is the processor speed ?
8. Do you have an oscilloscope or logic analyzer for troubleshooting/debugging?
9. You posted the code as one single line. Can you reformat it with some carriage returns so that it is readable ?

 

[ol boy]

This is from my 4r70w transmission controller. The whole code is at the bottom of the thread in the miscellaneous project section. I'm cutting a pasting this from the picaxe mobile phone app.

I'm running a 20x2 at 8Mhz. The input pulse train idles high and does a short pulse width after the falling edge. I believe the negative going duty cycle stays the same for the whole speed range.

I'm wanting some idea at what speed does the interrupt routine just have enough time to process the interrupt before the next falling edge is detected. At 60 mph the speed freq is around 160 hz. I just want to make sure the first time I blast the car up through 120mph it doesn't do anything goofy like command a down shift because the speed input becomes garbage.

 

[Goeytex]

The time that a command takes to process & execute depends upon the command and the processor speed. These times are not published and can only accurately be determined by measurement. As a rule of thumb/ guesstimate, some folks use 250 us per command, but I have found this to be unreliable for calculating critical timings.

If we assume that the signal is 160 hz, then that is a time period of 6.25 milliseconds. IF we then assume that the signal is low for 1 ms, that gives a processing window of 5.25 ms between pulses. IF IF IF, each command in the interrupt routine takes 250 us then you could theoretically process 21 commands between pulses. This is terribly rough calculation and should be considered no more than a a wild guess.

You need to characterize the incoming signal by taking scope or logic analyzer measurements at different speeds. Is the pulse width really fixed? What is it?

Then I would take an 08M2 or any other Picaxe and make a little jig that replicates the signal using a pot that controls the speed. Then send that signal to the main controller or another jig running your interrupt routine and see at what speed it fails. Empirical data is always more reliable than wild guesses or theoretical calculations, as it allows for the "unknowns"

 

[ol boy]

When using the HINT pins for input interrupts does it matter how big or short the duty cycle is? The interrupt flag is triggered on a falling or raising edge. I'm not sure the input signal has to be reset back to its idle level before the interrupt flag is cleared and enabled like with a software interrupt scheme. A raising edge won't cause an interrupt flag as its looking for a falling.

Using the swag time of 250us with only 7 commands to check for toflag, see if w15 is greater than 1, inc w15, clear the flag, endif, enable interrupt, and return. Should take 1.75 ms to complete. I'll scope it to see what the conditioned output form looks like then try to reproduce it.

Thanks. Ryan

 

[AllyCat]

Hi Ryan,

My guess is that your code as shown will miss some pulses (at 320 Hz), but whether that's catastrophic will depend on the exact program code and structure.

The execution times of many PICaxe instructions have been "unofficially" documented (I'll look for the thread if you're interested), but can vary significantly between different chips (at the same raw clock speed). The more recent PICaxes (M2 and X2) are actually slower than previous devices (e.g. because they have to manage a larger address space). The "fastest" instructions (driving a pin High or Low) execute in about 200 us (at 8 MHz) but many instructions are much, much slower. A jump (conditional or direct) takes about 500 us and a RETURN (from subroutine) a surprising 1 ms.

But another factor is that (AFAIK) even the X-series devices support only a "Polled" interrupt facility. This means that the "current instruction" being executed (anywhere in the "main" program) must finish before the interrupt is serviced. I don't know exactly what constitutes an "instruction" at the PICaxe interpreter level (SEROUT a string of 20 characters at 2400 baud?) but even "non-blocking" instructions such as LOOKUP can run extremely slowly.

However, if your code is running correctly with an 8 MHz clock at 60 mph, can't you just increase the PICaxe clock to 16 MHz (with re-defined "calibration constants" as necessary)?

Cheers, Alan.

 

[Pongo]

Just FYI, I believe the Ford controllers run with a clock speed of around 24/27 MHz and I imagine they are programmed in assembler so they will be operating way faster than even a 16 MHz picaxe.

 

[ol boy]

Thanks for the replies. I could read the drive shaft speed instead of the Ford VSS output. The drive shaft speed would produce pulses at about half the speed of the VSS. Just change the sampling times to capture the same 1 to 1 ratio of pulses to mph.

Maybe I need to start looking into doing a pure embedded system written in C and asm. Please take a look at the full trans code in the miscellaneous project area.

Thanks Ryan

 

[Goeytex]

Maybe I need to start looking into doing a pure embedded system written in C and asm. Please take a look at the full trans code in the miscellaneous project area.

That's what I would do for this application. Instead of 200us to 400us processing overhead per command, you will be looking at 1us to 4us, depending upon the processor, compiler,and clock speed.