"Principles, Semaphores and Queues"
The principles will discuss the design considerations that have application to a broad range of embedded system. Write Short interrupt routines Limit the number of tasks Avoid creating and destroying tasks Avoid time-slicing Encapsulate semaphores in separate functions Encapsulate queues in separate functions
Encapsulating Queues: consider encapsulating queues that tasks use to receive messages from other tasks. we wrote code to handle a shared flash memory. That code deals correctly with synchronizing the requests for reading from and writing to the flash memory. Since any task can write onto the flash memory task input queue, any programmer can blow it and send a message that does not contain a FLASH_MSG structure.
Hard Real-Time Scheduling Considerations"
Hard Real Time Systems: Systems were time constraints are absolutely critical Soft Real Time Systems: Systems with time constraints where minor errors are tolerated The obvious issue that arises in hard real-time systems is that you must somehow guarantee that the system will meet the hard deadlines. The ability to meet hard deadlines comes from writing fast code To write some frequently called subroutine in assembly language. If you can characterize your tasks, then the studies can help you determine if your system will meet its deadlines.
"Saving Memory and Power"
Saving memory: Embedded systems often have limited memory RTOS: each task needs memory space for its stack. The first method for determining how much stack space a task needs is to examine your code The second method is experimental. Fill each stack with some recognizable data pattern at startup, run the system for a period of time
Program Memory: Limit the number of functions used Check the automatic inclusions by your linker: may consider writing own functions Include only needed functions in RTOS Consider using assembly language for large routines
Data Memory: Consider using more static variables instead of stack variables On 8-bit processors, use char instead of int when possible
Few ways to save code space: Make sure that you are not using two functions to do the same thing. Check that your development tools are not sabotaging you. Configure your RTOS to contain only those functions that you need. Look at the assembly language listings created by your crosscompiler to see if certain of your C statements translate into huge numbers of instructions.
Saving power: The primary method for preserving battery power is to turn off parts or all of the system whenever possible. Most embedded-system microprocessors have at least one powersaving mode; many have several.
The modes have names such as sleep mode, low-power mode, idle mode, standby mode, and so on. A very common power-saving mode is one in which the microprocessor stops executing instructions, stops any built-in peripherals, and stops its clock circuit. This saves a lot of power, but the drawback typically is that the only way to start the microprocessor up again is to reset it. Static RAM uses very little power when the microprocessor isn't executing instructions Another typical power-saving mode is one in which the microprocessor stops executing instructions but the on-board peripherals continue to operate. Another common method for saving power is to turn off the entire system and have the user turn it back on when it is needed.
"Host and Target machines"
Native tool chain: Compiler: translates C source files to machine instructions, produces object files. Linker: resolves addresses of different object files in terms of offsets from base address of program Loader: loads program, modifies absolute addresses in executable based on actual starting location in physical memory
Tool chain for embedded systems: Cross-compiler Cross-assembler Linker/locator No loader
Cross-Compilers: Assume that your C code compiles with native compiler and runs correctly on host. What kinds of things go wrong in moving code to target? Using functions before declaring Using old style function declarations
Word sizes (and hence int variables) may be different C structs may be packed differently Alignment restrictions may change data layout or limit accesses
Cross Assembler: The tool you will need if you write any program in assembly language is cross assembler.
"Linker/Locators for Embedded Software"
Linker: Determines addresses of labels that assembler could not resolve. o Typically extern functions & variables defined in other files. Assembler will have marked as needing to be fixed: o o Instructions referencing these labels Data (pointers) initialized to address of other variables
The linker puts together files, fixing up the address references between the files. If unresolved labels exist at this point, it is a fatal error.
Locator: Quite different functionality than native linker o Determines final memory image of program No loader will come along after and fix up addresses o Locator can do this because:
No other program will be in memory at runtime; no resource conflicts Locator can determine final address of everything, including kernel and library functions called in application code Locator includes a mechanism for programmer to determine placement in memory o Some parts need to be in RAM, others in ROM
Handling initialized data: How does normal tool chain handle initialization in code at right? How can it be handled in embedded tool chain? o o o Initial value must be in ROM. Variable must be in RAM. Value must be copied at startup.
No loader, so application responsible for copying. o Many locators will automatically insert code to copy, but may require tinkering. Common technique: copy shadow segments (with initial values) from ROM to RAM at startup.
Other initialization issues C standard specifies that any uninitialized non-stack variable starts with value of zero. o May not be true of your embedded tools. o Startup code may be inserted to do this, but dont count on it.
Constant strings: char *sMSg = Reactor is melting!; o o o Where does the system store the constant string? Few problems if only operation involving string is printing it. What if you modify string? strcpy (&sMsg[11], OK);
Perfectly legal C o Cross-compilers deal with this problem in different ways.
Locator Maps: Maps provide a quick way of checking where the locator actually placed segments. Useful to know variable and function addresses when debugging.
Executing out of RAM: RAM is often faster than Flash and ROM.
To exploit, startup code must copy program from ROM to RAM, then transfer control to it. Consider new challenge for locator: o Build a program that is stored at one address (in ROM), but will run correctly at a different address (in RAM). A bit tricky: requires support from the RTOS development system.
"Getting Embedded Software into the Target System"
Several alternatives: o Write it to flash memory on target o o o Put it in ROM or PROM, then insert chip into system Use a ROM emulator Use an in-circuit emulator
Replaces microprocessor in target system Overlay memory in emulator can be used instead of memory on target Useful for debugging not in shipped products
PROM Programmer Used to program executable code into a PROM. The PROM should be socketed so it can be replaced easily. PROM approach good for production mode, but inconvenient for test and debug during development. o Painful to pull, reinsert chip for every new test.
Not surprisingly, other alternatives have been developed.
ROM emulator Plugs into PROM/ROM socket. Looks like ROM to target. Has connection to host to allow easy changes to memory.
Much easier than burning a new PROM. Used during development and debugging only. Not shipped with working system!
Flash memory Flash is field programmable Host can connect to target, cause flash to be reprogrammed directly without replacing any ships. Software (bootstrap program) must be on target system to copy data from host to flash memory. Tricky: cannot execute from flash while reprogramming it. Must copy itself from ROM to RAM and then run from RAM.
Field upgrades
Product code fixes are very expensive. Product must be brought in to have memory upgraded or customer must install the memory upgrade. Some products lend themselves to automatic field upgrading. Satellite TV receivers + set-top cable boxes Cell phones Software radios Tricky to do. Flash code could get corrupted (communication fails during update), then nothing works.
"Debugging Techniques"
Avoiding software bugs The best approach is to produce bug-free code, but no software is completely error-free. Although it cant be your principal technique for ensuring software quality, you are foolish to not do a lot of testing. Unfortunately, embedded systems pose special challenges for testing.
Problems testing on target system
Target system may not be available or stable early on while code is being written and debugged. Difficult to generate pathological timing scenarios. o Impossible to test all combinations, and difficult to know which combinations will cause a problem.
Bugs are often not repeatable. o o Often show up with specific event sequence and timing. Tough to generate using standard software test suites.
Embedded systems generally lack extensive logging capabilities to identify cause of failure.
"Testing on Host Machine"
Testing on Host Machine Separate application code into hardware dependent code (HD) and hardware independent code (HI). Essential: creation of a clean interface between HD and HI. HI is just C code. Easy to compile and run on other computers. HD portion is more problematic
Testing the system ISRs and interrupt handlers must also be divided into HD, HI parts. o Required organization: HD code must call the HI part. o Scaffold code can then mimic HD code, calling HI code to test response. This can be more effective, thorough than testing HI code on target.
Example: generating tick interrupts. o Clearly responsibility of test scaffold code, but how to implement?
Generate automatically at fixed time intervals?
Generate directly and explicitly? The latter is preferred: more likely to turn up bugs of strange combinations of events occurring within same tick interval. Important to create a scripting mechanism for convenience. Script files read by the scaffold code, specify events to generate. o Since events are platform specific, youll want your own script language. General form: Take this action (call this function) with these parameters at this time.
Not difficult to create simple parser to read files, generate appropriate function calls, yet rewards are significant. o o Simple, powerful tools can make a big difference. Well worth the effort to consider test in design phase, build tools that make testing easier.
Scaffold code can output results interleaved with script input easy to follow and confirm correct operation.
Limitations of testing on host Things you cant test include: o Software/hardware interaction o o o Response time and throughput Shared data problems (and timing pathologies) Portability problems (endianness, packed data-structures, etc.)
But it makes sense to test as much as you can before moving to the target for testing, which is more difficult.
Instruction set simulators Another way to test on host; does not use scaffold code. Uses actual binary code (constructed by cross-compiler and linker/locator) that will run on target. o Avoids portability problems with word-size, endianness, etc.
Simulator running on host executes code. This approach tests both assembly and C code (unlike the scaffold approach). What are requirements for simulator?
Simulator requirements Must simulate all assembly instructions of target CPU. Must simulate all built in peripherals at some level. o o Timers, DMA, I/O devices, etc. Must simulate RAM and ROM at proper addresses.
Should provide a debugger interface: o o o Set breakpoints Examine/change memory Single step execution
Should track timing in terms of instructions or bus cycles. o Can give accurate measurements of run time of various routines. Can help say something about throughput and response time.
Simulator limitations Commercial system will know nothing about your custom hardware. o Add yourself? Will vendor make source code available? Simulator is unlikely to discover obscure shared-data bugs. o You are no more likely to do exhaustive testing
Tough to use scripting because simulators dont usually give access to hosts keyboard, screen, and file system. o 425 simulator is unusual in this regard by design.
Recommendation: use simulator to test what cannot be tested using scaffold approach:
Startup code, ISRs, response time, etc.
"Using Laboratory Tools"
Voltmeters, ohmmeters multi-meters Oscilloscopes
These are used for checking is the hardware working
Graphs voltage vs. time, potentially multiple signals Can select trigger to start its operation Capture signals, store in memory, graph on screen. Can track many signals simultaneously, Up to several hundred if you are willing to pay and make all the connections! Typical operation: trigger on symptom of problem, then look backward through captured data to see source of problem. Hardware emulator that plugs into CPU socket, appears to target system as regular microprocessor. Programmable or controlled by host.
Logic analyzers
In-circuit emulators
Software-only monitor/debugging kernel
Small debugging program in ROM on target system that knows how to receive software over serial line, copy to RAM, and
run it.
