TMS320F28379D: Event Driven Application Architecture

Torsten,

         Not sure I understand your concern. In the IDLE mode, all peripherals can be kept alive i.e. the peripherals can be doing their thing. I make this distinction because both STANDBY & HALT modes shut down the peripheral clock domain. Any configured interrupt can wake up the device from the IDLE condition. For example, data received through a serial port. 

In the CPU timer case, the timer is going to keep running and generating interrupts. So, I don’t quite understand your concern about a “race” condition.

Hi,

then let us switch to a serial port example. Let us assume, I have configured the serial port for reception and enabled the interrupt for that port. After that, I switch the CPU to IDLE mode:

1) configure serial port
2) IDLE()

Now, what can happen is, that the interrupt fires between 1) and 2), leaving the CPU in IDLE mode forever (if the interrupt fires after 2, everything is fine). The only use for the IDLE() mode, I could think of, would be to have everything being handled in interrupt handlers, which would result in an empty main loop, which then could be safely converted into a loop calling IDLE().

The ARM (Cortex-M) architecture solves this problem by having the interrupt setting a flag that will be consumed be the corresponding instruction (WFE).

regards,

Torsten

If interrupt fires between 1 & 2, it will be serviced normally, since the CPU is active. After ISR execution, CPU is put into IDLE. It would then wake up the next time the serial port receives the data and hence triggers an interrupt.

Yes, that is exactly how I understand the documentation too! But what I don't understand, is how I could utilize the IDLE() instruction other then handling all my application logic in the interrupt service routines, having an empty main() function that just calls IDLE(). Right?

An other example: In the C2000 Ware 3.02, there is an example called lpm_ex1_idleware.c, which configures a GPIO pin as output and set it initial to 1 and configures one GPIO pin as input and as an interrupt source. The interrupt handler of that input pin, sets the output pin to 0. The main loop of the example is setting the output pin back to 1, once the ISR returns and then goes into IDLE state.

So basically, I would expect that the intended behavior of this example is that one could trigger the external input and that the output goes shortly to 0 and then back to 1:

main()
{
    ...
    while(1)
    {
        GPIO_writePin(1, 1);              // Line A
        SysCtl_enterIdleMode();        // Line B
    }
}

__interrupt void xint1ISR(void)
{
    GPIO_writePin(1, 0);
    Interrupt_clearACKGroup(INTERRUPT_ACK_GROUP1);
}

Now, what would happen if the xint1ISR() would be served after line A, but before line B? The output would be switched to 0 and would stay there, as the CPU would go to IDLE().

Is there something I'm missing? How would a typical C2000 application look like, that makes use of the IDLE mode to conserve power?

how I could utilize the IDLE() instruction other then handling all my application logic in the interrupt service routines, having an empty main() function that just calls IDLE(). Right?

Sorry I don’t understand what you are asking here. Could you please rephrase/clarify? If I have understood your requirement correctly, your application will normally be in IDLE. When a wakeup signal arrives, the device comes out of IDLE, executes the ISR and go back to IDLE and waits for the next wake up signal. Your main() will not have much code, except for the one putting the device into IDLE. All the "action" happens in the ISR.

So basically, I would expect that the intended behavior of this example is that one could trigger the external input and that the output goes shortly to 0 and then back to 1:

Correct. 

Now, what would happen if the xint1ISR() would be served after line A, but before line B? The output would be switched to 0 and would stay there, as the CPU would go to IDLE().

Correct. Since XINT is asynchronous, it can happen anytime. Now, while the CPU is in IDLE, the next time XINT happens, the CPU would come out of IDLE , execute the ISR and go back to main() and again go to IDLE. The desired sequence is determined by the application. From the device point of view, while it is in IDLE, a wakeup signal would wake it up and after ISR execution, control would go back to main(). 

How would a typical C2000 application look like, that makes use of the IDLE mode to conserve power?

The C2000ware example is all we have.