Go Down

Topic: Uneven respone to interrupt command (Read 1 time) previous topic - next topic


sinusoidal signal is coming from a inductive trigger "looking" to the flywheel

I calculated this delay AFTER the ignite to reduce any unforeseeable time delay.


I calculated this delay AFTER the ignite

Then the processor has nothing better to do so poll the trigger input (much faster than interrupts) and do two loops to time the delay and pulse width.

Rob Gray aka the GRAYnomad www.robgray.com

Udo Klein

@soulid: I understand your point that you want consistent responses. However you will always pick up some jitter, for example while digitizing the analog signal. What I am aiming at: what is the maximum RPM of you engine and what angular resolution do you really need.

Example: suppose max RPM = 12000 RPM and angular resolution ~ 1°. Then resolution in clock cycles = 16 000 000 * 60 / (12 000 * 360) = 222 ticks (or 13 microseconds). --> You better be precise to ~5 microseconds.

With regard to consistent responses. Turn of all interrupts the Arduino provides by default. Then switch on only what you ***really*** need. Actually as it was already proposed you can do this without any interrupts at all.

However since you need to do some other stuff at the same time this might not be an option. I can think of several solutions:

1) Disable all other interrupts but the interrupt for the signal you want to delay. Process the delay in your interrupt routine and then go back to the main program. It follows that you main program must not rely on any timing functions and must not lock interrupts for more than say << 10 microseconds

2) Same as above but instead of a delay enable an additional interrupt in the timer code and set up a timer interrupt for the ouput.

3) Same as (1) but instead of generating the output in software use the PWM hardware to generate just this single pulse. Take care to disable the PWM early enough.

There are some mandatory actions here:
a) Read the datasheet on interrupts, especially timer interrupts.
b) Analyze the Arduino interrupt setup code (not to much and not to hard to understand). Do not forget the interrupts caused by communications
c) Analyze the LCD libraries if it has anything timing critical that might block interrupts.
Check out my experiments http://blog.blinkenlight.net


However you will always pick up some jitter,

He could always use an LPC ARM, they can be set to have jitter-free interrupts :)

At 12000RPM he has 5mS between pulses and the pulses don't look to be very long so most of that time is spent waiting for the next pulse or, writing to an LCD or calculating a pulse width.

LCDs are slow but I think if the data for it is put in a ring buffer and for example one byte sent every in inter-pulse period that shouldn't get in the way.

I'm thinking pseudo code like this

loop {
  wait for trigger
  do pulse
  calc value
  write stuff to LCD ring buffer if necessary
  read a byte from ring buffer and send to LCD

No interrupts required (and disable any default interrupts) and "wait for trigger" is a tight polling loop.

Rob Gray aka the GRAYnomad www.robgray.com


That does not work for me. Think about:

1) Analog read with a prescaler set to 16: 104 microseconds (and I have two of them)
2) LCD write with 4bit: takes more than 20 microseconds as well

Both single functoins are far to slow to "wait" for the trigger

What I did was the following

Code: [Select]



function Interrupt action
put PIN13->high
jump to calculate_only_once_after_interrupt

function calculate_only_once_after_interrupt

function do-other-things
if x==8->x=1

if x=1
If the last LCD write was more than 25mS away-> write LCD
if x=2
read analog1

if x=2
read analog2


if x=8
write Pinxyz HIGH

The function do-other-things will lead to do one action out of 8 when called. That ensures proper execution of each function.

Go Up