22-10-2016, 02:45 PM
1460544060-7.doc (Size: 77 KB / Downloads: 4)
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 cross-compiler 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 power-saving 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 Instructions referencing these labels
o 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 Initial value must be in ROM.
o Variable must be in RAM.
o 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.
o 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 don’t count on it.
• Constant strings: char *sMSg = “Reactor is melting!”;
o Where does the system store the constant string?
o Few problems if only operation involving string is printing it.
o 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).
o 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 Put it in ROM or PROM, then insert chip into system
o Use a ROM emulator
o 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.
Avoiding software bugs
• The best approach is to produce bug-free code, but no software is completely error-free.
• Although it can’t 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 Often show up with specific event sequence and timing.
o 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.
o 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, you’ll want your own script “language.”
o 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 Simple, powerful tools can make a big difference.
o 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 can’t test include:
o Software/hardware interaction
o Response time and throughput
o Shared data problems (and timing pathologies)
o 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 Timers, DMA, I/O devices, etc.
o Must simulate RAM and ROM at proper addresses.
• Should provide a debugger interface:
o Set breakpoints
o Examine/change memory
o Single step execution
• Should track timing in terms of instructions or bus cycles.
o Can give accurate measurements of run time of various routines.
o 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 don’t usually give access to host’s 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:
o Startup code, ISRs, response time, etc.