embedded system development development environments software techniques tools

36
Embedded System Development Development Environments Software Techniques Tools

Upload: kathleen-fields

Post on 04-Jan-2016

221 views

Category:

Documents


4 download

TRANSCRIPT

Page 1: Embedded System Development Development Environments Software Techniques Tools

Embedded System Development

Development Environments

Software Techniques

Tools

Page 2: Embedded System Development Development Environments Software Techniques Tools

System Startup

• Not all that different than what a desktop PC does• But, we are more aware of it• Two phases

– Hardware phase• Executes some code that will initialize hardware and memory

(such as interrupt vector tables)• Similar to BIOS in a PC

– Software phase• A little more initialization (ROM checksum, move user code

from ROM to RAM…)• Eventually user code starts running

Page 3: Embedded System Development Development Environments Software Techniques Tools

Interrupt Servicing

• An interrupt is basically an asynchronous function call– That is, it looks and acts like a function call but the program

doesn’t control when they occur– Similar to a callback in a GUI based system (Swing, MFC,

Cocoa, …)

• Issues to be addressed– Where does the interrupt service routine (ISR) code reside?– What must be saved prior to executing the ISR?– What must be restored after executing the ISR?– When should interrupts be enabled or disabled

• Are nested interrupts allowed?

Page 4: Embedded System Development Development Environments Software Techniques Tools

Interrupt Servicing

• Executing an interrupt is a multi-step process– Acknowledge the interrupt– Find the ISR

• This is stored in the system portion of memory which is initialized at startup

– Save the system context• Varies with system but at least save the address of the next

instruction• This is where we must address issues of “reentrant” or “thread safe”

code if we are to allow nested interrupts

– Load the ISR address into the program counter– Disable interrupts (optional – may/may not allow nested interrupts)– Resume execution at address in the program counter (the ISR

address)

Page 5: Embedded System Development Development Environments Software Techniques Tools

Interrupt Servicing

• Save the system context– This context is called the stack frame since it is a

bunch of data that is pushed onto (save) and popped off of (restore) the stack

• This is perhaps the hardest step– The more information that must be saved/restored,

the more time the ISR is going to take to complete– The more time the ISR takes to complete, the

greater the chance of missing further interrupts (events)

Page 6: Embedded System Development Development Environments Software Techniques Tools

Alternative to Interrupts

• Polling– Rather than an event announcing its arrival

by creating an interrupt, the software checks for the event on a periodic basis

• Sound familiar?– This is exactly why the buttons are so

troublesome to deal with on the Stamp modules

Page 7: Embedded System Development Development Environments Software Techniques Tools

Run-time Environment

• Two primary components– Start up code

• Run Power-On-Self-Test (POST)• Relocate user code from ROM to RAM• Initialize system data (hardware and software) if any• Turn execution over to user code

– Run-time libraries• Similar to the various APIs that Java offers us• The availability and completeness is entirely up to the provider• For WinCE Microsoft has somewhat reduced the MFC capabilities

w.r.t. Windows versions• VxWorks has extensive libraries• Convenient• Maybe optimized [size or speed], maybe not

Page 8: Embedded System Development Development Environments Software Techniques Tools

Run-Time Libraries

• Perhaps the biggest issue is support (or non-support) for dynamic memory allocation– In general dynamic memory allocation should be avoided in

embedded systems• Programmers often get it wrong• Embedded systems often have limited amounts of heap

memory available• Memory fragmentation clean-up is difficult and time consuming

– Some run-time libraries do offer it but be careful• Typically it is extremely slow• If you have to do it, allocate a large block once and reuse it

when needed (do your own memory management)– If it’s not included in the library, you must write your own

memory manager

Page 9: Embedded System Development Development Environments Software Techniques Tools

Object (code/data) Placement

• In the PC world we don’t worry about this (unless we’re writing a device driver)– We “build” our application and without considering the

intermediate steps of compile, assemble, link, and load

• In a memory mapped embedded system we must be cognizant of all these steps– Some memory locations are assigned to specific memory

addresses– Some micro-controllers include high-speed registers within the

memory map– Some micro-controllers assign I/O pins to specific memory

addresses– ROM/RAM may share the same memory address space

Page 10: Embedded System Development Development Environments Software Techniques Tools

Example Memory Map

Page 11: Embedded System Development Development Environments Software Techniques Tools

Build Phase

• Compile– This pretty much stands alone

• Assemble– We may need to use inline assembly code if our compiler allows it– If it doesn’t we may need to modify the compiler generated assembly

code then assemble it– We may need to write Assembly language from the start to meet system

constraints• Link

– We may need to force certain variables to reside at specific memory locations rather than generalized relocation

– Note the “register” keyword in C is merely a hint• Load

– Push the code onto the processor via an external port– Burn the code into a ROM memory device and plug it into a socket– Burn a mask ROM at the silicon foundry

Page 12: Embedded System Development Development Environments Software Techniques Tools

Software Techniques

Page 13: Embedded System Development Development Environments Software Techniques Tools

Inline Assembly Code

• Inline assembly codefor (int i = 0; i < 10; ++i) {

x = x * 42;asm(“

mov acc, xout 0x4000

“)}

• Again, if the compiler doesn’t allow it you can always modify the assembly generated by the compiler prior to the assemble stage

Page 14: Embedded System Development Development Environments Software Techniques Tools

Memory-Mapped Access

• If you’ve ever written C or C++ code (or read a C or C++ book) and wondered what the volatile keyword is for, here it is…

• It keeps the compiler from doing in register optimizations on variables that may get modified outside the realm of the compiler’s knowledge (“side affects”)

Page 15: Embedded System Development Development Environments Software Techniques Tools

Bitwise Operations

• Since many devices are manipulated with a single bit (LED on/off, button press/release) many data items get bit-packed into single words

• To manipulate them you must use bitwise operators– The Stamp software (and others) provide named

registers at the bit level (PIN0, PIN1…)

Page 16: Embedded System Development Development Environments Software Techniques Tools

Bitwise Operations

• Basic operations– Selective-set

• Set selected bits to 1 while leaving others unchanged (OR w/1)– Selective-complement

• Invert selected bits while leaving others unchanged (XOR w/1)– Selective-clear

• Set selected bits to 0 while leaving others unchanged (AND w/0)– Mask

• Extract the values of selected bits and set others to 0 (AND w/1)– Insert

• Replace selected bits with a given pattern (AND to clear, then OR)

– Clear • Set all bits to 0 (XOR with self)

Page 17: Embedded System Development Development Environments Software Techniques Tools

Pointer Usage

• Replace array accesses with pointers– Some compilers generate better code this way– Not clear if this is still true – certainly not true

for “good” compilers

for (int i = 0; i < 10; ++i) {dst[i] = src[i];

}

// assumes 0 terminationvoid *d = dst;void *s = src;while (*d++ = *src++);

Page 18: Embedded System Development Development Environments Software Techniques Tools

Byte Ordering

• This one gets you every time

• Big Endian vs. Little Endian– Specifies the byte ordering of multi-byte

data structures

• Especially a problem if you’re interfacing multiple systems together

Page 19: Embedded System Development Development Environments Software Techniques Tools

Big Endian

• Big Endian– Most significant byte is stored in the lowest

memory address

• Little Endian– Least significant byte is stored in the lowest

memory address

• Middle/Mixed Endian– Byte-swap and Word-swap

Page 20: Embedded System Development Development Environments Software Techniques Tools

Byte Ordering

MSB LSBbyte 0byte 1byte 2byte 3

LSB

MSB

byte 0

byte 1

byte 2

byte 3

address0

1

2

3

Little Endian

MSB

LSB

byte 3

byte 2

byte 1

byte 0

address0

1

2

3

Big Endian

Data structure (e.g. 32 bit integer):

Page 21: Embedded System Development Development Environments Software Techniques Tools

Watchdog Timer

• This is basically a technique for system reset if things seem to be taking too long– i.e. it’s a last resort

• During development– Programmer estimates the amount of time a piece of code should

take under normal circumstances• Count assembly lines/machine cycles• Measure with a logic analyzer

– Tie a timer to an interrupt that resets the system– Set the value of the timer to longer than the expected time of the code

• During run time– Start the timer at the beginning of the section of code– At the end of code execution, reset the timer– If the timer goes off (interrupts the system) then something was wrong

and the system needed a reset

Page 22: Embedded System Development Development Environments Software Techniques Tools

Flash Memory

• It’s basically a solid state hard drive• Can be reprogrammed after deployment• Allows for field upgrades• But beware, the system must be designed so

that if a bad write occurs it can somehow be recovered– When flashing the BIOS on my laptop the program

insists that the power come from the cord and not the battery

Page 23: Embedded System Development Development Environments Software Techniques Tools

Toolsets

Page 24: Embedded System Development Development Environments Software Techniques Tools

Toolsets

• For the most part we’ve covered them

• Three basics – Remote debugger– ROM emulator– Logic analyzer

Page 25: Embedded System Development Development Environments Software Techniques Tools

Remote Debugging

• We discussed this last week• The key word is “intrusion”• The more features you add to your

debugger the more intrusive [on the embedded system] it gets

• The more intrusive the debugger is, the more likely it is to hide real bugs or create fictitious bugs

Page 26: Embedded System Development Development Environments Software Techniques Tools

Remote Debugging

• Some processors have a debug kernel as part of the system memory area

• This is essentially an ISR used to communicate with a host system

• They’re inexpensive but very intrusive and definitely not real-time

Page 27: Embedded System Development Development Environments Software Techniques Tools

ROM Emulator

• Since our code resides in ROM there is no easy way to modify it

• A ROM emulator is just as the name implies– A device that physically replaces the ROM

chip in the systems– Embedded system sees it as a ROM chip– Host system sees it as a remote debugger

Page 28: Embedded System Development Development Environments Software Techniques Tools

ROM Emulator

• Can be used for downloading/testing code• Can be used for monitoring/debugging code• Provides real-time debugging capabilities• Minimally execution-time intrusion• Physically intrusive• Expensive• Not always available for the processor you’re

using

Page 29: Embedded System Development Development Environments Software Techniques Tools

ROM Emulator

Page 30: Embedded System Development Development Environments Software Techniques Tools

Logic Analyzer

• A device for debugging without modifying the embedded system in any way (well, almost)

• An embedded system is basically a device that controls a bunch of electrical signals in a way that performs a useful function

• A logic analyzer is a device for capturing those signals when they don’t behave as we want or expect them to

Page 31: Embedded System Development Development Environments Software Techniques Tools

Logic Analyzer

• Two modes– Timing mode

• The analyzer decides when to capture the signals– State mode

• The embedded system decides when and tells the analyzer to capture the signals

– In either case, what you get is a bunch of digital waveforms that you must analyze

• These waveforms represent– Memory (bits, zeros and ones)– Interrupts (pulses)– Timing signals (clocks)– I/O signals– Anything you design them to represent

• This is the lowest level of debugging and is not for the faint of heart• The book talks more about them but it doesn’t mean a lot if you don’t

have one in front of you, which we don’t…yet.

Page 32: Embedded System Development Development Environments Software Techniques Tools

Logic Analyzer

Page 33: Embedded System Development Development Environments Software Techniques Tools

Oscilloscope

• Similar in function to a Logic Analyzer but captures/displays analog signals– May convert to digital for storage and later

analysis

Page 34: Embedded System Development Development Environments Software Techniques Tools

Oscilloscope

Page 35: Embedded System Development Development Environments Software Techniques Tools

Multi-meter

• Whereas Logic Analyzers and Oscilloscopes capture dynamic (over time) events the multi-meter captures static events– A/C voltages– D/C voltages– Resistance– etc.

Page 36: Embedded System Development Development Environments Software Techniques Tools

Multi-meter