• AVR Freaks

Hot!100% event driven programming vs CPU hogging

Author
acharnley
Super Member
  • Total Posts : 309
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: offline
2019/07/17 05:16:51 (permalink)
0

100% event driven programming vs CPU hogging

Hi,

As I've played more and more with PIC's I've found myself leaning into a peculiar way of programming where interrupt events trigger other peripherals which in turn may trigger the initial instigator in a type of callback. In the meantime the CPU outside of an interrupt is in sleep and the actual main() function doesn't do anything. Sound familiar?

For example:


void timerPeriodUsbDisabledWithoutTuningInitInterrupt (void) {

adcReset();
TIMER_PERIOD_INT_SET(timerPeriodUsbDisabledWithoutTuningInterrupt);
adcInstallAndStart(adcStartPeriodTimerInterrupt);
}


In this example the ADC is being used to sum record over one period cycle but there must be at least one ADC measurement before the next timer period fires. As the period is variable this is potentially a race condition, so to solve it the timer sets the next interrupt for itself, stops, and sets the interrupt for the ADC to restart the timer. The ADC starts the timer and installs a looping interrupt into itself.

Outcome - the timer always has an ADC read to use, the CPU is drawing minimal power. No branch checks to see if there's an ADC read (wasted CPU).

What do you think?

Andrew
#1

4 Replies Related Threads

    NKurzman
    A Guy on the Net
    • Total Posts : 17599
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: 100% event driven programming vs CPU hogging 2019/07/17 05:31:45 (permalink)
    +1 (1)
    It is one method that is useful in many situations. But wasted CPU cycles assume the CPU has something else to do, or needs to sleep to save power.
    #2
    NorthGuy
    Super Member
    • Total Posts : 5541
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: offline
    Re: 100% event driven programming vs CPU hogging 2019/07/17 06:39:47 (permalink)
    +1 (1)
    Typically, if you have something which needs fast reaction (such as receiving fast UART), I use only one interrupt - this saves time where it matters - at the beginning on the interrupt - you can drop all code which detects what kind of interrupt has happened. I wouldn't be able to use other interrupts anyway because this would increase the latency for my fast interrupt.
     
    On PIC16, if there's no need for the fast interrupt, I usually don't use many interrupts. Often, I don't use interrupts at all - just a big loop checking all the tasks. What's the point for the interrupt when your ISR code must go through the list to figure what kind of interrupt has happened?
     
    This is different on PIC24 where interrupts are vectored and there are multiple interrupt levels. Thus you can have a fast interrupt, and also number of other lower-priority interrupts, which can be put in order. Here interrupt-driven development makes much more sense. In combination with DMA, it leaves only very slow maintenance tasks in the main loop.
     
    #3
    LdB_ECM
    Senior Member
    • Total Posts : 125
    • Reward points : 0
    • Joined: 2019/04/16 22:01:25
    • Location: 0
    • Status: offline
    Re: 100% event driven programming vs CPU hogging 2019/07/17 08:26:32 (permalink)
    0
    It's probably easier to write it as what it is a state machine.
    In your case above you have a flip flop or a state machine with only two states.
    #4
    NKurzman
    A Guy on the Net
    • Total Posts : 17599
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: 100% event driven programming vs CPU hogging 2019/07/17 09:24:49 (permalink)
    +1 (1)
    LdB_ECM
    It's probably easier to write it as what it is a state machine.
    In your case above you have a flip flop or a state machine with only two states.


    Why?  There is not one correct way to write code.  The Project requirements and the Programmer are supposed to "engineer" a solution.
    #5
    Jump to:
    © 2019 APG vNext Commercial Version 4.5