Selecting tools, development environments, and operating

systems for embedded systems’ development

Craig DUFFY

craig.duffy@uwe.ac.uk

Bristol UWE, UK.

Overview of talk

• This talk will have 3 sections– Firstly we will look at the options with regard

to targets/boards.– Then we will consider the selection of host

development tools and environments– Finally, I will conclude with some tests for

cross development tools, along with a brief discussion of those tests.

Target options

• There are broadly 3 main options with a new target board– Go with the existing vendor’s system

• This may also have lots of unpleasant side effects

– Build your own system• Has a lot of positives and negatives

– Port an existing OS onto the board• This requires some careful thought and planning

Vendor’s Systems

• You may be convinced by the fact that the vendor built the board * then they therefore should be the most suitable people to supply the operating system and development tools– This is less true than some of you may think

• You often end up with buggy, un-documented and un-supported systems

• The choice may force you to use a poor quality compiler/host development environment.

• The libraries and start-up code may be difficult to port to a better system (e.g. gcc)

• You could end up with difficult/expensive licensing problems* Quite often the vendor may not have designed or built the board

Vendor’s Systems - questions• There are some very important questions to ask before going with a

vendor solution– Is it open source/GPL?

• If it isn’t life is going to be tough– Is there a support community?

• If they don’t understand the question, then that (no!) is your answer!– Do you have to rely on one, vendor specific, compiler/libraries?

• You may end up fighting against a very bad compiler.– Who else uses it? New releases? Other architectures?

• You could end up learning a lot of redundant, non-portable skills.– Relationship to/links with a BSP/BIOS?

• Can you use other BSPs? How easy is it to change/interrupt the machine start-up sequence?

– Use of specialist tools – i.e. for debugging the system• Do you really want to buy an ICE?

Going alone!

• You may have a very specific requirement that doesn’t really require a large amount of, or even any, OS support.

• If you already have your own application code then implementing a small executive to support this code may be an option.

• This options requires some thought…

Going Alone – Pros and Cons

• Positive– You are in control

• Don’t have to worry about 3rd party code

– Debugging your own code is (often) simpler

– No licensing problems– Can focus on

application problems

• Negative– You are in control

• Now you can really screw things up

– May end up re-inventing a lot of wheels

– Tends to be one-off, bespoke development

– Will either re-write or have to interact with the native OS

Porting an existing OS #1

• This requires some specific planning– What is on the board?

• CPU, Memory, MMU, install method, – Porting to a new architecture is a large job – board ports are

more straight forward– Memory requirements for Linux/NETBSD could be a problem –

can get onto < 4MB, but is it worth it?» Do you really need/want a file system?

– Does the target have a MMU, MPU?» May require extra porting

– Relationship to existing BSP and installation method can be a tough cookie. JTAG, BDM support? How does it boot? Can you recover your system?

– Debugging the system – what debug support do you have?

Porting an existing OS #2

– Which OS?• This is obviously related to the previous question

– What do you require from the OS?• Scheduling? TCP/IP? Web services?

Windowing? Users?

– If a larger system (i.e. Linux) doesn’t fit• You could try ECOS or RTEMS

– For MMUless systems you can chose uClinux.

Porting an existing OS #2.2

• If you go for Linux, which one?– A standard distribution

• Debian, RedHat– Can be large

– A embedded specific one?• MonteVista, BlueCat,

– Good support and documentation at a cost

– Build your own• Get the kernel, library and applications that you need

– Make take more time, but you will better understand the system.

Porting an existing OS #3

– What application area?• Does the application require an element of real-

time response– You may have select an r-t extension to Linux.

• Do you require certain features?– TCP/IP, security,

• Will you require specific device drivers?– Can find existing ones or port them.

Option 3.5! A mid way

• There is an alternative to resting with a vendor’s system and a full blown port.

• This is to port a compiler and library system for your board– Using gcc and Newlib could be a good choice

• This is a good choice for a smaller system or one that it is difficult/impossible to replace the existing OS.

• This approach allows you to use good open source development tools hosted on Linux/Unix.

Option 3.5

• This approach requires – Porting gcc for your host

• Not too big a job for existing architectures.• Requires the writing of some compiler’s library start-up and

crt0.s code.• End up with great compiler and tools.

– Porting a library• Need to carefully select the library – Newlib is a good choice

for many boards• Port a number of stubs to the native OS – if the feature is not

OS supported then you won’t get that feature

Selection of X-development tools

• This selection will be influenced by your choice of target OS– With Linux/NetBSD/Ecos life will be much

simpler– For all the other options

• Vendor OS• Home made executive• gcc/newlib/vendor OS

– You may have to chose you tools with care and test them.

Selection criteria

• A fair amount has been written about the criteria required for embedded and real-time language selection, however compiler rather than language choice is an important issue.

• In many ways, if one has chosen C (or even C++), then the gcc suite fulfils most needs and can be a good standard by which to judge other candidate compilers.

• The criteria are given, in no particular order to the following slide

Criteria• Good linker control – linker language• Assembler linkage – a bit OTT in gcc• Good machine specific coverage• Variety of tools – objdump, ar etc• Debugger interface• Good library support – small sized libraries e.g. uClibc• Assembler output - standard assembler?• Optimisation levels• Conformance to standards• Documentation• Support community• Compiler maturity• Portability• Variety of output formats – elf, srecord, binary• Open source – at least the crt0.o should be available!

Why test the compiler/OS?

• As stated previously these tests are mainly of use to those working with standalone or vendor OS code.

• The compiler or OS manual may make claims that code is position independent and ROMable, but it is worth being suspicious of such claims.

• Small, test programs may run, but you could end up in trouble when trying out larger, more realistic applications.

Tests for compilers

• Four tests are given, all of which are very simple. They are– Initialised data– Large arrays– Long jumps– Downloadable library code

Initialised data #1

• Initialised data– Will require

linker/Operating System involvement

– Is easy to test • Simply create an

initialised global data item.

//test initialised dataint test = 8;

void main(){

}

Initialised data #2

• Unlike uninitialised data, which only requires an empty block of memory, initialised data requires the memory and also for it to be filled with the data. This must be done correctly so that later references to the data will point to the correct locations

• This frequently requires both linker operations and operating system code.– If you don’t have the OS you may have to write these routines

and this can lead into complex problems.

• Can be avoided by creating all data as uninitialised and write initialisation routines at start-up.

Large arrays #1

• It is worth simulating the use of very large data areas with your compiler to see what happens. You can get surprising results

void main(){ char big_array[0x32000], *ptr; //200k array

ptr = &big_array[017000]; *ptr = 0xaa; *ptr++;; big_array[0]=0xbb; //first element big_array[0x2a2000] = 0xcc; //32k from end big_array[0x320000-1]= 0xdd; //end}

Large arrays #2

• The previous program caused errors with a number of compilers– One created the code, but only allocated a 32k stack

based array, but it did not report an error• This was because it used register indirect with an offset that

was too small• The code seemed to work but actually just wrapped around

– Another created assembler instructions that were illegal

– Many required there to be changes to an initialisation file (cstart, crt0…)

Long jumps #1

• Attempt to simulate what a large development will look like by creating a routine call over a large address range

• You may need to insert the assembler manually into the code

/ test a long jumpvoid faraway(void );void main(){

faraway();}_asm {.rept 0x10000nop}void faraway(void){

}

Long jumps #2

• The code creates a non-local jump

• Often short jumps are just PC relative offsets - +/-127 bytes

• When they get larger they may be placed into jump tables and require initialised data as in the previous problem

• Some compiler can put all jumps into jump tables – and thus create initialised data

Library Support

• Some code will obviously require OS support – ie open(), signal()

• Some may be easily ported – ie printf()

• Some should work without OS support – ie sprintf()

• Check libraries like the string and maths ones as they may require OS support – for example calls to malloc().