Interrupts and main loop on lpc1769

lpcware · ‎06-15-2016

Content originally posted in LPCWare by dragilla on Wed Nov 16 03:59:52 MST 2011
Hello,
I am quite new to the uP programing so I need some help to understand some things.
Perhaps you help me me out.

I have the following, theoretical situation:
1) 1 main loop, working with constant frequency, say 100hz (so every 10ms). One loop cycle takes about 5ms, so theretically there is 5ms free processor time every cycle
2) I have a function that is triggerred by am external interrupt. This function is very simple and fast, takes lot less processor time that the main loop

I want the interrupt function to always react in an instant manner, that is : it is triggered and the ouput of it is always set with a predictable delay.
But what I also need is that the loop cycle always occurs regularly, because I'm doing some time based calculations there.

Is it even possible to do? I guess it's not because if I want the interrupt function to have priority, then when an interrupt comes in the middle of the loop cycle then the loop cycle is paused to service the interrupt. Is this right?

If so, then maybe another approach is possible, namely maybe I can read the timestamp in the loop function and based on that timestamp I can do my calculations?

Let me know if you understand what I mean and what you think about it.

cheers,
--
Luke

lpcware · ‎06-15-2016

Content originally posted in LPCWare by dragilla on Wed Nov 16 08:35:49 MST 2011

Quote: Polux rsv

I must find my PowerCommander project and send you some code. It was done on LPC2138, but timers are the same on LPC1769.

Please do, it would be a great help for sure. Thanks.

ps: if you want, I think I can get you schematics of a good power source filters for a car/motorcycle. I've worked on a commercial project once that used WismoQucick powered from the car battery. It was mounted on some bikes with success as well, so the power source filters must have been good. Let me know if you want it. I will be getting it for myself anyway :)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Polux rsv on Wed Nov 16 08:27:37 MST 2011
Manipulating ignition or injection pulses is the same job: get pulses edges, measure frequency and pulse width, compute new shorter, longer or delayed pulses, and generate new signal.

I must find my PowerCommander project and send you some code. It was done on LPC2138, but timers are the same on LPC1769.

Angelo

lpcware · ‎06-15-2016

Content originally posted in LPCWare by dragilla on Wed Nov 16 08:18:39 MST 2011
Hm, I don't want to build a power commander. I want to use signals from my current ECU (I use Yec Ecu btw) and just pass them through, retard them a bit or kill them in an extreme situation.I will read all about the capture-match mechanism and see what I can do with it, thanks :)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Polux rsv on Wed Nov 16 07:43:10 MST 2011
If your goal is to measure, capture ;) and generate ignition pulses, you take the wrong way using EXTINT functions. You should use the hardware timers which provide you exactly what you need: Measure digital pulse width and frequency. Generate exact pulse width. Read the manual about capture and match function.

In few words, a timer has a free running counter. A capture function "captures" the counter value in its register when an event is present on an input pin. On the opposite way, the match function generate an event on an output pin when the free running counter matches the preset value. All the input and output events can generate interrupts, which doesn't need to "react instantly", as registers contains counter values when the event appened. Playing with various input events and counter values, you will get frequency and pulse width. By calculation, you could place exact delayed pulses.

That's what I used when I built my own PowerCommander :D It worked very well until I pluged it on the bike and started the motor. All the spikes caused by the ignition were not enough filtered and caused software issues. So start learning about power supplies filtering :D

Angelo

lpcware · ‎06-15-2016

Content originally posted in LPCWare by dragilla on Wed Nov 16 06:32:02 MST 2011

Quote: Zero

Come on, what are you trying to do? Is it rocket science? How many cycles can your external interrupt ISR interrupt your timer?
120 cycles? That's 1 µs at 120MHz. So your timer could be late 0.01% :eek:

As I wrote in another thread - I'm building a motorcycle traction control system. To be true, there will be 4 external ISR's + the timer driving the main loop.
And each ISR will take definately more than 1us. Maybe even 1 ms. So wost case scenario I get 4 ms delay, which is 40%. And being off by 40% when calculating lean angle and speed will get me crashed :)

So maybe, just maybe I can measure somehow how much am I delayed with my loop and adjust my calculations accordingly?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Wed Nov 16 06:24:02 MST 2011

Quote:

Instant - An almost imperceptible space of time...In other words ASAP and always with the same delay.

What's imperceptible? Imperceptible for you or for my scope or for E.T.?

Sorry, I can't work with this words. Unfortunately I've wasted too much time with electronics and not with philosophy :mad:

Therefore I'm used to words like 'nanosecond' :rolleyes:

Quote:

It is... when there are no other ISR's with higher priorities. If they were then I guess I can't be sure how often my main loop gets executed?

Come on, what are you trying to do? Is it rocket science? How many cycles can your external interrupt ISR interrupt your timer?

120 cycles? That's 1 µs at 120MHz. So your timer could be late 0.01% :eek:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by dragilla on Wed Nov 16 05:43:21 MST 2011

Quote: Zero
What's 'instant' ?

Instant - An almost imperceptible space of time (as defined here: http://www.thefreedictionary.com/instant) :)
In other words ASAP and always with the same delay.

Quote: Zero

That's, of course, only working if the interrupt priority is higher. Otherwise 'tail-chaining' puts your interrupt behind a possibly active interrupt :eek:

Well this is basically all I'm asking about.
I want two things guaranteed: main loop frequency exactly as I set it and Interrupt service time stable and predictable.

Quote: Zero

Isn't that done by your 'if(rit_timer_counter)'?

It is... when there are no other ISR's with higher priorities. If they were then I guess I can't be sure how often my main loop gets executed?

I guess I'd need two cores to have the delays 100% stable and predictable. With one core I can be sure of only one process - the one with the highest priority.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Wed Nov 16 05:15:38 MST 2011

Quote:

1) have the external interrupt servicesed in an instant

What's 'instant' ?

Quote:

Interrupts always take just 12 cycles and then 12 cycles to return from servicing.

That's, of course, only working if the interrupt priority is higher. Otherwise 'tail-chaining' puts your interrupt behind a possibly active interrupt :eek:

Quote:

2) have the main loop running at 100hz rate (no matter what)

Isn't that done by your 'if(rit_timer_counter)'?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by dragilla on Wed Nov 16 04:53:45 MST 2011
Ok. Please forgive my the mess.

This is what I call my main loop:

extern uint32_t rit_timer_counter;
int main(void)
{
    // enable and init the timer - interrupt
    init_rit_timer( TIME_INTERVAL ); // (12000000/40 - 1) which is 10 ms
    enable_rit_timer();

    while (1) {

        if(rit_timer_counter) {

            // here goes my code which assumes this part is executed once every 10ms.

            // reset timer
            rit_timer_counter = 0;
        }
    }
    return 0 ;
}

And this is the ISR function that I want to react in an instant (and to produce output with a predictable delay:

void External_IRQHandler (void)
{
    // process data
    // set ouput
}

I hope this clears up things a bit.

Lets forget about priorities. I want to know is it possible to:
1) have the external interrupt servicesed in an instant
2) have the main loop running at 100hz rate (no matter what)

If so, how?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Wed Nov 16 04:41:18 MST 2011
Yes, you are right, I don't understand that :mad:

#1 So you have 2 'independent' processes? Whats an 'independent' process? Are we still talking about interrupts?

#2 This 2 processes are: 1. main loop 2.ext. interrupt 3.timer (interrupt?) :confused:

#3 Which theoretical interrupt priority did you set for your interrupts?

#4 Perhaps you should just write and show us a theoretical sample, so questions could be answered without guessing more practical :)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by dragilla on Wed Nov 16 04:24:06 MST 2011
I think you misunderstood.
These are two independent processes: main loop and ISR.
Main loop does check the flag triggered by another ISR that is driven by an internal timer. But this has nothing to do with the ISR driven by an EXTERNAL Interrupt.

And the external interrupt ISR (lets call it ISR2) is the one I want to react in an instant.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Wed Nov 16 04:21:06 MST 2011

Quote:

1) 1 main loop, working with constant frequency, say 100hz (so every 10ms). One loop cycle takes about 5ms, so theretically there is 5ms free processor time every cycle

That's theoretical nonsense. How can you determinate the 'frequency' of a main loop?

First theoretical step is to generate a time base (SysTick x ms), set a flag inside its ISR and wait for this flag in main loop :eek:
So you are sure that this part of your program is executed every x ms :)