Embedded Systems Design Europe - October 2007 - (Page 34)

microcontrollers Listing 11 A pointer-to-function that calls code in Listing 10. _asm(“FCLR I”); /* if (idle_condition()) { /* Wait_code[0] = 0xF37D; /* _asm(“FSET I”); /* (*(void (*)(void))Wait_code)(); /* } else { /* _asm(“FSET I”); /* } lock interrupts */ idle condition reached? */ insert the WAIT instruction */ unlock interrupts */ call the wait code */ idle condition not reached yet */ unlock interrupts */ Listing 12 Disable the transition in every interrupt to wait mode by replacing the WAIT instruction at Wait_code[0]. #pragma INTERRUPT my_ISR void my_ISR(void) { Wait_code[0] = 0x04F3; } /* M16C enters ISR with interrupts locked */ /* insert the RTS,NOP instruction pair */ mode transition from ISRs can be made to work in the M16C, but it requires replacing the WAIT instruction with something else (such as NOP or RTS). Yes, I am talking about self-modifying code, but I don’t know of any other option for the M16C. Luckily, the M16C is a von Neumann architecture, so it can execute code from the RAM address space. The piece of self-modifying machine code can be quite small. You deﬁne a 4-byte array in RAM, as in Listing 10. This machine code represents a tiny C-callable function that executes the WAIT instruction and returns to the caller. In the background loop, you modify this code and call it using a pointer-to-function, as in Listing 11. You must disable the transition in every interrupt to wait mode by replacing the WAIT instruction at Wait_ code[0], as in Listing 12. With this design, an interrupt can occur at any machine instruction between FSET I (enabling interrupts) and executing the instruction at Wait_ code[0]. Thus, any interrupt that preempts the idle loop disables the wait mode, which accomplishes the goal of an interruptsafe transition to idle mode. ATOMIC LOW-POWER STATES Running the MCU at full-speed all the time will never lead to a truly low-power design, even if you use the lowest-power MCU available. The biggest power savings are only possible by frequently switching the MCU to a lowpower sleep state under the software control. The simplest foreground/background software design requires that the transition to a low-power state be atomic, or at least interrupt-safe. This requirement does not apply when you use a more sophisticated architecture, such as a preemptive kernel or a realtime operating system. A preemptive kernel executes a special idle task when no other tasks are ready to run because all are blocked waiting for events. Most kernels provide a way to customize the idle task (using callback functions or macros), so that you can conveniently implement the transition to a low-power state inside the idle task. The main difference between a preemptive kernel and a foreground/ background system is that as long as tasks are ready to run, the kernel doesn’t switch the context back to the idle task. Consequently the transition to a low-power mode is much simpler, because it doesn’t need to occur with interrupts disabled.9 Unfortunately, a preemptive RTOS isn’t always an option for a low-end MCU, which simply might not have enough RAM to accommodate a preemptive RTOS. Miro Samek (miro@quantum-leaps.com) is the president of Quantum Leaps, LLC, a provider of lightweight, open-source, state machine-based application frameworks for embedded systems. REFERENCES 1. 2. 3. 4. 5 6 7. 8. 9. Freescale Semiconductors, MC68HC908QY4/D datasheet, 2003. Texas Instruments, MSP430x1xx Family User’s Guide, 2006. Atmel, ATmega169 Datasheet, 2005. Atmel, AT91SAM7S32 Datasheet, 2005. ARM Ltd., ARM v7-M Architecture Application Level Reference Manual, 2006. ARM Ltd., Cortex-M3 Technical Reference Manual, 2006. Luminary Micro, LM3S811 Microcontroller datasheet, 2006. Renesas, M16C/62 Group (M16C/62P) Hardware Manual, 2003. Samek, Miro and Robert Ward, “Build a Super Simple Tasker,” Embedded Systems Design, July 2006, p. 18. http//:www.embedded.com/columns/technicalinsights/190302110. Any such interrupt will replace the code in Wait_code[0] with the RTS,NOP instruction pair that immediately returns to the background loop, so the WAIT instruction won’t survive to the point when the background loop actually comes around to execute it. 34 OCTOBER 2007 | embedded systems design europe | www.embedded.com/europe 028-029-030-031-032-033-034_ESDE34 34 10/10/07 11:38:28 http://www.embedded.com/columns/technicalinsights/190302110 http://www.embedded.com/europe

Table of Contents Feed for the Digital Edition of Embedded Systems Design Europe - October 2007

Embedded Systems Design Europe - October 2007 Contents Linux Set to Dominate Torvalds Updates Linux Kernel ARM Establishes Smart Card Foundry Program Emerson Buys Motorola's Embedded Comms Group LynuxWroks and TTTech to Cooperate on Avionics MontaVista CEO Looks for Acquisitions in Europe Ready: Multiprocessing Technology Provides Opportunity Automotive to Drive MCU Market New Supporters Join COM Express Group Analyst Weighs TI Versus Xilinx Versus PicoChip Cover Feature: Embedded Systems Security Has Moved to the Forefront Trace Exposes the Toughest Real-Time Bugs Employ a Secure Flavor of Linux Use an MCU's Low-Power Modes in Foreground/Background Systems Transporting Video Over Wireless Networks New Products Advertising Contacts

Embedded Systems Design Europe - October 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.