RAM Execution
While building the AirMobile application, a noticed some warnings from the ULP Advisor tool. In particular, the warning was about floating point operations, which are said to be processor intensive and consume many instruction cycles, which wastes time and energy. The 16-bit MSP430 microcontroller device is best designed for simple controlling logic, as opposed to complex arithmetic computations.
Floating point operations on an MSP430 CPU requires the compiler to generate a significant number of instructions. This requires additional code instruction execution to perform the operation and consequently results in additional power and energy consumption.
The suggestion is to re-architecture your program to avoid or minimize the number of math functions. Alternatively, move the processing-intensive function to RAM as code execution from RAM consumes much less power than Flash.
I choose the second alternative: move the processing intensive function to RAM
This is not difficult to accomplish
First of all, I need to Create a load = FLASH, run = RAM memory section in the device linker command file. Reserve a memory region in FLASH to store the functions and a memory region in RAM for copy/execution.
Before
RAM: origin = 0x2400, length = 0x2000 INFOA: origin = 0x1980, length = 0x0080 INFOB: origin = 0x1900, length = 0x0080 INFOC: origin = 0x1880, length = 0x0080 INFOD: origin = 0x1800, length = 0x0080 FLASH: origin = 0x4400, length = 0xBB80 FLASH2: origin = 0x10000,length = 0x14400
...
After reserving 0x200 bytes for RAM_EXECUTE and 0x200 bytes for FLASH_EXECUTE. Notice the new starting addresses (origins) & lengths.
RAM_EXECUTE: origin = 0x2400, length = 0x0200 RAM: origin = 0x2600, length = 0x1C00 INFOA: origin = 0x1980, length = 0x0080 INFOB: origin = 0x1900, length = 0x0080 INFOC: origin = 0x1880, length = 0x0080 INFOD: origin = 0x1800, length = 0x0080 FLASH_EXECUTE:origin = 0x4400, length = 0x0x200 FLASH: origin = 0x4600, length = 0xB980 FLASH2: origin = 0x10000,length = 0x14400
Create a section to load from FLASH_EXECUTE & run from RAM_EXECUTE:
/****************************************************************************/ /* SPECIFY THE SECTIONS ALLOCATION INTO MEMORY */ /****************************************************************************/ SECTIONS { .bss : {} > RAM /* GLOBAL & STATIC VARS */ .sysmem : {} > RAM /* DYNAMIC MEMORY ALLOCATION AREA */ .stack : {} > RAM (HIGH) /* SOFTWARE SYSTEM STACK */ /* NEW CODE BEGINS HERE: ADDED TO HANDLE RAM EXECUTION */ .run_from_ram: load = FLASH_EXECUTE, run = RAM_EXECUTE /* NEW CODE ENDS HERE: ADDED TO HANDLE RAM EXECUTION */ .text : {}>> FLASH | FLASH2 /* CODE */ .text:_isr : {} > FLASH /* ISR CODE SPACE */
Then all the functions that uses floating point math can be decorated with the following pragma
#pragma CODE_SECTION(SENSORS_Map,".run_from_ram")
Because I use division and multiplication, these functions are pulled in from the real-time library. These processor intensive functions should also be relocated to RAM to optimize application for power.
You can find out whether your application uses many of these functions by looking at the output map file and searching for rts430*.lib. For example
rts430xl.lib : mult16_f5hw.obj (.text) rts430xl.lib : div16u.obj (.text)
Add the following lines to the linker command file to redirect these objects into the FLASH_EXECUTE//RAM_EXECUTE area
.text:rts430.lib_div : { rts*.lib<div16u.obj>(.text) } .run_from_ram .text:rts430.lib_mult : { rts*.lib<mult16_f5hw.obj>(.text) } .run_from_ram
Note that relocating the functions to RAM requires the use of a customized command linker file. This method is undetected by the ULP Advisor tool and the remark will still be issued. Once you can confirm the RAM execution in your code, you can suppress the remark by disabling the option for this rule in the Project's ULP Advisor setting.