{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

MSP430_Microcontroller_Basics_Chapter 6

MSP430_Microcontroller_Basics_Chapter 6 - CHAPTER 6...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
C H A P T E R 6 Functions, Interrupts, and Low-Power Modes A well-structured program should be divided into separate modules—functions in C or subroutines in assembly language. There is nothing special about this in embedded systems. If you wish to write subroutines in assembly language, you need to know how arguments are passed, local variables allocated, and results returned. This is occasionally useful for efficiency but the main reason for studying these details is to assist the debugging of C programs. It is particularly important to understand the central role of the stack. Interrupts are a major feature of most embedded software. They are vaguely like functions that are called by hardware rather than software. The distinction sounds trivial but it makes them much harder to handle because the processor must be able to return correctly to its activity before it was interrupted. The application note MSP430 Software Coding Techniques (slaa294) describes the overall structure of a typical, interrupt-driven program for the MSP430 and describes a range of techniques to ensure that programs are robust and can easily be debugged. The final topic in this chapter is the range of low-power modes of operation. They are described here because the MSP430 needs an interrupt to wake it from a low-power mode. In fact we see that no extra effort is usually needed to handle low-power modes in interrupts: The MSP430 automatically goes to active mode when an interrupt is requested, services the interrupt, and resumes its low-power mode afterward. www.newnespress.com
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
178 Chapter 6 6.1 Functions and Subroutines It is good practice to break programs into short functions or subroutines, for reasons that are explained in any textbook on programming: It makes programs easier to write and more reliable to test and maintain. Functions are obviously useful for code that is called from more than one place but should be used much more widely, to encapsulate every distinct function. They hide the detailed implementation of an activity from the high-level, strategic level of the software. Functions can readily be reused and incorporated into libraries, provided that their documentation is clear. I find that many students are reluctant to break programs into functions. Frankly I think that the real reason is laziness but “efficiency” is usually offered as an excuse. The cost of calling a function is tiny. Looking back at Listing 4.14, the statement call #DelayTenths takes five cycles and the ret requires a further two. This is usually negligible. There is a further overhead in setting up the arguments for a more complicated function, retrieving the return value, and saving registers, which is covered in the next few sections, but the time is still unlikely to be significant. Against this, functions make better use of RAM because local variables need exist only while the function is being called. The space can be released when the function has finished and is available for the rest of the program. In
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}