Building Embedded Systems - fbi · icm In-Car Multimedia Labs ! Hochschule Darmstadt IN-CAR...

© All Rights Reserved. The contents of this document cannot be reproduced without prior permission of the authors.

Andreas Knirsch | [email protected]

Building Embedded Systems Chapter 4: Building Applications

mailto:[email protected]

IN-CAR MULTIMEDIA LABS, Andreas Knirsch | Building Embedded Systems

icm In-Car Multimedia Labs !Hochschule Darmstadt

www.h-da.de

fbi Fachbereich Informatik

h_da

Agenda

• Motivation • Embedded Applications • Build Environment • Compiler & Linker • Build Automation • Build Optimization


www.h-da.de IN-CAR MULTIMEDIA LABS, Andreas Knirsch | Building Embedded Systems


h_da


Motivation

„I already know how to code

and compile code!?“



www.h-da.de


h_da

Building Embedded Systems: The Map

Applications

Operating System

Bootloader

Hardware Platform

ECO

SYST

EM



www.h-da.de


h_da

Assumption

• Software is developed on „Host“i.e. a developer’s workstation

• Software is running on „Target“i.e. an embedded DevBoard

… this is a cross-compile environment!



www.h-da.de


h_da

Reasons for cross-compilation

• utilizable computational power and memory for the build process i.e. on developer’s WS, on high performance build server

• no on-target build-environment with respect to optimized file-system/storage resourcese.g. compiler, dev-libs, build-utils

• different HW architectures for host and targete.g. (host == x86-64) && (target == x86-32 |ARM | PPC | …)



www.h-da.de


h_da

HOST

Building Embedded Systems: The Map

Applications

Operating System

Bootloader

Hardware Platform

ECO

SYST

EM

TARGET




h_da

Embedded Applications

What are we building?




www.h-da.de


h_da

The interface

• ... to the user. via user interface (e.g. GUI, buttons, speech recognition/synthesis, etc.)

• ... to other systems. via communication channels (i.e. network connections, fieldbus systems, etc.)

• ... that provides the system's service(s)



www.h-da.de


h_da

The "main loop" approach

• No operating system (OS) required. • Sequential processing:

(1) retrieve sensor values (or input events)

(2) process data

(3) control actuators

(4) - proceed with step 1 - • Minimal overhead. • Deterministic behavior. • Not able to process parallel/concurrent tasks. • Limited maintainability for complex systems.

(see also [Wietzke, 2012, pp.3-4])



www.h-da.de


h_da

Standing on the shoulders of an OS provides the capability to ...

• ... structure the logic into tasks, computed in parallel (or concurrently).

• ... prioritize certain logical components.

• ... use abstract device drivers.

• ... use standardized system services. (e.g. memory management, communication interfaces, error routines, synchronization features)

• ... reuse the application for another platform.

(see also [Wietzke, 2012, pp.3-4])



www.h-da.de


h_da

Characteristics of ES (… or the Limitations)

• User Interface GUI, headless, speech recognition/synthesis, button etc.

• Connectivity WiFi, ethernet, bluetooth, serial, fieldbus (e.g.CAN) etc.

• Mobilityweight, power consumption, size etc.

• Field of Usageclimate conditions, shock resistance etc.

• Availability„always on“, fast startup, suspend mode etc.

… those „may“ have impact on the

software part.



www.h-da.de


h_da

Important Requirements (… or the System’s Qualities)

• Functional Suitability Satisfy the stated or implied needs. (i.e. completeness, correctness and appropriateness)

• Reliability Maintain its level of performance under stated conditions for a stated amount of time.

• Performance Efficiency Cope with limitations and provide adequate performance (i.e. time behaviour, resource utilization)

• UsabilityEnable an efficient use, support learn of operation and be attractive to the user.

see also [ISO/IEC 25010:2011]

this list is far from being extensive!!!

constructive aspects !!!



www.h-da.de


h_da

How to build reliable & efficient SW?

• Use experience (if available)yours & others

• Stick to coding standards MISRA, JPL etc.

• Reduce complexitymodularize the software into interdependent components(apply a vertical and horizontal model of abstraction to achieve a separation of concerns)

• Review the codeexpensive, prioritize parts to review (e.g. on complexity)

• Test the system … and test … and … make heavy use of both unit and integration tests

if not:

gather experience … its an

socialization process



www.h-da.de


h_da

Experience:„Automotive Embedded Systeme“

• Be aware of different memory types. • Explicitly define tasks’ priority. • No use of dynamic memory after init. • Rely on POSIX system abstraction. • Use an event based communication system. • Use shared memory for communication. • Make use of finite state machines.

[Wietzke and Tran, 2005]

this is only a small snapshot



www.h-da.de


h_da

Experience:„The Pragmatic Programmer“• Take responsibility

provide options; don’t make lame excuses • Communicate

be a listener and get back to people; • Don’t live with broken windows

fix problems as soon as they are discovered • Remember the big picture

don’t see the system only as accumulated features • Don’t repeat yourself

imposed/inadvertent/impatient/interdeveloper duplication • Make it easy to (re)use

If its not easy, people won’t use it (… and rewrite it)[Hunt and Thomas, 1999]

again, this is only a small snapshot



www.h-da.de


h_da

Experience:„The Pragmatic Programmer“ (II)• Eliminate effects between unrelated things

design components that are self-contained • Estimate

to avoid surprises • Keep knowledge in „plain text“

… or alternatively the lowest common denominator • Always use source code control

even for a single-person one-week throw-away prototype • Fix the problem, not the blame

even for a single-person one-week throw-away „hack“ • If it can’t happen, use assertions to ensure

break things early[Hunt and Thomas, 1999]

again, this is only a small snapshot

…



www.h-da.de


h_da

Experience:„Effective C++“

… 55 Specific Ways to Improve Your Programs and Designs. !

Chapter 1: Accustoming Yourself to C++

[Meyers, 2005]

get language skills

— business fluent —



www.h-da.de


h_da

Experience:DEVELOP SOFTWARE!!

• Design • Implement (code!) • Test • Review (or get your software reviewed!) • Refactor (redesign & optimize your code)

comply to mature standards

may improve the portability and

reliability of your code



www.h-da.de


h_da

Coding Standards: MISRA C/C++

Motor Industry Software Reliability Association !

• Software Development Standard that aims for portable and reliable code

• Initially targeted for automotive ES adopted by aerospace, telecom, medical devices etc.

• MISRA-C:2012 contains 142 rules …checkable using static program analysis

• … and 16 directives more open to interpretation, related to measurements, derived form requirements and design

this means

automatic check is possible



www.h-da.de


h_da

Coding Standards: „The Power of 10“

Rules for Developing Safety-Critical Code: 1. Avoid complex flow constructs (e.g. goto, recursion)!2. All loops must have fixed bounds.!3. Avoid heap memory allocation.!4. Restrict functions to a single printed page.!5. Use a minimum of two runtime assertions per function.!6. Restrict the scope of data to the smallest possible.!7. Check return value of all non-void functions, or cast to void.!8. Use the preprocessor sparingly.!9. Limit pointer to a single dereference & do not use func. ptr.!10.Compile with all possible warnings active.

[Holzmann, 2006]



www.h-da.de


h_da

Coding Standards: NASA/JPL

Laboratory for Reliable Software at the Jet Propulsion Laboratory - LaRS@JPL !

• 31 Rules (22 „shall“ + 9 „should“)additionally inherits MISRA-C:2004 rules (shall + should)

• 5 Levels of compliance language, predictable execution, defensive coding, code clarity, MISRA shall, MISRA should

• Free availableclearly written and understandable, referencing both related „MISRA“ and „Power of Ten“ rules

[http://lars-lab.jpl.nasa.gov]

http://lars-lab.jpl.nasa.gov



www.h-da.de


h_da

Modularize: Integrated Modular Architecture• design self-contained components

independent with a single, well defined purpose (cohesion) • agree on functional interfaces

to define the services provided • utilize effective intercommunication

to reflect the components’ interdependencies (coupling) • consider non-functional requirements

e.g. memory footprint, required temporal behavior

divide and conquer!

• reduce the complexity • mitigate error propagation • enable failure handling



www.h-da.de


h_da

Test the System: Unit Tests

• Test a very small unit of your system this may vary from a single method to a system component

• Each test case should be independentthis requires substitutes (e.g. method stubs, mock objects)

• Very effective to find problems early … or after refactoring and implementing change requests

• Tests should be executable (semi-)automatictest often should be made attractive

• Can be implemented independent of the operational codeeven before the first line of code is written, following the idea of Test Driven Development (TDD)

… may cause self-confidence :-)



www.h-da.de


h_da

Boost Test Library

• A C++ unit test framework • Provides Components for test programs,

organizing tests into test cases and suites.#define BOOST_TEST_MODULE MyTest!#include <boost/test/included/unit_test.hpp>!!int add( int i, int j ) { return i+j; } // func to test!!BOOST_AUTO_TEST_CASE( my_test ) {! BOOST_CHECK(add(2,2) == 4); // continues on error! BOOST_CHECK_EQUAL(add(2,2), 4); // continues on error! BOOST_REQUIRE(add(2,2) == 4); // throws on error!! if(add(2,2) != 4)! BOOST_ERROR( "Ouch..." ); // continues on error! if(add(2,2) != 4)! BOOST_FAIL( "Ouch..." ); // throws on error! if(add(2,2) != 4) throw "Ouch..."; // throws on error!}



www.h-da.de


h_da

Running a Boost Test Suite

• first compile !

!

• … then run.

$> g++ -o mytest -lboost_unit_test_framework mytest.cpp

<terminal>

$> ./mytest !Running 1 test case...!*** No errors detected!!$> ./mytest --log_level=all # verbose mode !Running 1 test case...!Entering test suite "MyTest"!Entering test case "my_test"!mytest.cpp(7): info: check add(2,2) == 4 passed!mytest.cpp(8): info: check add(2,2) == 4 passed!mytest.cpp(9): info: check add(2,2) == 4 passed!Leaving test case "my_test"!Leaving test suite "MyTest"!*** No errors detected!

<terminal>



www.h-da.de


h_da

Test the System: Integration Tests

• components are tested as assembly to check if they are fit together (i.e. their composability)

• verifies: function & performance & reliability to state wether the components are interoperable and compatible and the assembly fulfills the requirements

• components are seen as black-boxes while unit tests are white-box tests



www.h-da.de


h_da

Test the System: Continuous Integration (CI)

• First named and proposed as part of XP(eXtreme programming)/agile approaches

• Integrate early and oftento avoid the pitfalls of „integration hell“

• Any change to the code repository initiates a build (and test) of the system requires version control with atomic commits, automated builds (and test)

• „Everyone commits to the baseline every day“ and „Every commit to the baseline should be built“

• CI software provides support e.g. Cruise Control (open-source, incl. email notification)




h_da

Build Environment

All I need is a compiler!?




www.h-da.de


h_da

HOST

Building Embedded Systems

Applications

Operating System

Bootloader

Hardware Platform

ECO

SYST

EM

TARGET



www.h-da.de


h_da

Our Goal: a Working System

wwarby (flickr.com)

That applies for the target- and the eco-system.

The Task: • Assemble the gears and get them turning. • For some cases it’s necessary to produce

custom gears that fit into the system.



www.h-da.de


h_da

Let’s take an alternative viewpoint …

• (embedded) SW development is craftsmanship … sure, it’s more than that. However, the implementation relies on knowledge, experience and usage of special skills.

• a craftsman utilize a special toolset… depending on the tasks to solve.

• a good craftsman knows the tools i.e. their usage, advantages/disadvantages, effects etc.

The term craftsman includes both men and women!



www.h-da.de


h_da

What tools are necessary to build ES?

makeitgreat (flickr.com)

... or: „Which tools do you already know?“



www.h-da.de


h_da

Choose your WeaponTOOLS!!!

The Task: • Put a nail into a piece of wood.

precondition postcondition



www.h-da.de


h_da

… but which one suits best? „An empirical study.“

1 1 2 4Result: • The given task can be solved with any of

the given tools. • The efficiency varies. • Different skills are required.



www.h-da.de


h_da

Essentials

• Text Editore.g. vi, emacs, gedit, nano, kate etc.

• Compilere.g. GNU Compiler Collection (gcc)

• Binutilse.g. GNU Linker (ld), GNU Assembler (as)

• Transfer Utilities for deploye.g. tftp, via UART, scp/rcp etc.



www.h-da.de


h_da

(semi-)automatic**

sourcecode

objectcode

executable binary

compiler linker

editor

requ

irem

ents

arch

itect

ure

desi

gn

deploy

* support through CASE tools** to be configured by developer

manual*

The Essentials’ Interplay



www.h-da.de


h_da

… but, a text editor and a compiler

• ... aren't sufficient for efficient or parallel development.

• ... don’t scale very well with the software's increasing complexity.

• … aren’t providing support on testing, profiling and debugging.

• ... don’t necessarily produce reproducible artifacts.



www.h-da.de


h_da

How to Improve Efficiency

• use an Integrated Devel. Environment (IDE) e.g. eclipse, netbeans, visual studio

• use Build Automatione.g. make, ant, autotools, jam, shell scripting

• use Automated Tests, Profiler and Debuggere.g. unit-tests, integration-tests, gdb, valgrind, LTTng

• use Virtualizationi.e. when no hardware is available yet

• use Version Control i.e. to support teamwork and different versions




h_da

Compiler & Linker

Probably the

most fundamental utilities

in Software Development?




www.h-da.de


h_da

The Compiler

sourcecode

objectcode

• Translates higher level into lower level code human readable source code into machine code

• May utilize a preprocessor and linker for a more convenient generation process

• May perform static code checks give hints on potential problems (warnings)



www.h-da.de


h_da

The Linker

objectcode

executable binary

• Link object code with librariesbuild your software upon a mature foundation !

• Static vs. Dynamic… or: at compile time vs. at runtime.



www.h-da.de


h_da

GNU Compiler Collection (GCC)

• Key component of the GNU toolchain beside: make, binutils, m4, debugger, build system, bison !

• Available for many HW architectures and OSs maintained since 1987 !

• The front end utilizes other tools for convenience e.g. linker

!

• Defacto standard for C and C++it also provides front ends for Java, Ada, VHDL, and others



www.h-da.de


h_da

g++: The GNU C++ Compiler

$> g++ --version!g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3!Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.!!$> i586-poky-linux-g++ --version!i586-poky-linux-g++ (GCC) 4.7.2!...!

• Know your tool identify the current version

<terminal>



www.h-da.de


h_da

g++: The GNU C++ Compiler (2)

$> g++ -o hello_world hello_world.cpp!$> ./hello_world !hello ES.!

• Use it: COMPILATIONTranslate source code to executable binary

#include <cstdio>!!int main() {! (void)printf("hello ES.\n");! return 0;!}!

hello_world.cpp

<terminal>

ARGS: -o <OUTPUT> <INPUT>

compile & link



www.h-da.de


h_da


$> ls !hello_world.cpp!$> g++ -c hello_world.cpp!$> ls !hello_world.cpp hello_world.o!!$> g++ -o helloworld hello_world.o!$> ./hello_world !hello ES.!

• Compilation without linkingcreate object file(s)

<terminal>

ARGS: -o <OUTPUT> <INPUT>

#1 preprocess, compile and assemble#2 link



www.h-da.de


h_da


$> g++ -v -c hello_world.cpp !Using built-in specs.!COLLECT_GCC=g++!COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper!Target: x86_64-linux-gnu!Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id —with-system-zlib …

• Take a look under the hood: verbose mode see how g++ was configured, the current environment etc.

<terminal>



www.h-da.de


h_da


--help Display available options!-o <file> Write to file!-I <dir> Add dir to include search path!-c Preprocess, compile, assemble!-g Generate debug information!-v Show commands & use verbose mode!--sysroot=<dir> Use dir as root for headers/libs!-Wall Enable all warnings!-O[level] Set optimization level

some notable options: $> g++ <options> input




h_da

Build Automation

„… don’t repeat yourself!“

[Hunt and Thomas, 1999]




www.h-da.de


h_da

Motivation: Reproducability

• We should be able to recreate any given version or release as long as the system is in development/maintenance.

• This requires a very good documentation or a formalized creation process.

• This includes both the system and the meta-system (= dev. env.).

> This is further supported through the use of version control!



www.h-da.de


h_da

Significance: The „Truck Factor“

• The number of people on your team who have to be hit with a truck before the project is in serious trouble. (a.k.a Bus Factor/Number)

• The "truck" can be substituted with vacation, illness, lottery win etc.

• Many projects rely on "heroes", which are expensive to replace when they "leave".

> Reproducibility reduce the number of „heroes“

and hence mitigate the risks.



www.h-da.de


h_da

Excursus: Recap on „Development Approaches“

• WaterfallSequential processes, where progress is seen as flowing steadily downwards.

• V-ModellExtension of "the waterfall“, that reflects the relationship between development and testing.

Analyse

Design

Implement

Test

Operate

UnitTest

Implement

Design

Analyse

IntegrationTest

Acceptance



www.h-da.de


h_da

Excursus: Recap on „Development Approaches“ (II)

• Iterative / IncrementalRepeated cycles (iterative), that focus on small portions of the system at a time (incremental) while covering all phases of the development process.

!

!

!

!

!

!

>> Builds the foundation for agile approaches. <<

initial planning

deploy

analyse

designimplement test

evaluate



www.h-da.de


h_da

Excursus: Recap on „Development Approaches“ (III)

Iterative/Incremental/Agile means …

• … you are able to handle deviations from the initial plan.

• … you have to build often.

• … you have to test often.

..but: DON’T REPEAT YOURSELF (DRY)!

source system



www.h-da.de


h_da

Build Automation means …

• Formalize the transfer process form source code to executable binary.

• If something can be described formal, it can be parsed and interpreted without human interaction.

• The goal is to make the creation process executable.

sourcecode

objectcode

executable binary

compiler linker

… a more precise build process.



www.h-da.de


h_da

Software must be usable

• This also applies to the Development Envionment. (incl. transformation, compilation, deployment)

• Improved usability of the tool chain supports more frequent building, testing and deploy.

• Build instructions ensure the code is used and transformed properly. (i.e. as intended)



www.h-da.de


h_da

Example: Project „Hello ES“

• Relies on C++. • Consists of 3 source files:

main.cpp, CHello.cpp, CHello.h • Has no meaning, just to demonstrate the use

of a set of tools. • To compile the project, you may type: shell>> g++ -o helloES main.cpp CHello.cpp

Just name all cpp files and you are fine :-)

Document this within a README file

and we are done, aren’t we? :-)



www.h-da.de


h_da

Example: Source of „Hello ES“// FILE: main.cpp!// DESC: impl. main routine!#include "CHello.h"!int main() {!! CHello myHello;!! (void)myHello.doit();!! return 0;!}

// FILE: CHello.cpp!// DESC: impl. CHello!#include "CHello.h"!#include <cstdio>!!int CHello::doit() {! printf("Hello ES\n");! return 0;!}

// FILE: CHello.h!// DESC: defines CHello!#ifndef CHELLO_H_!#define CHELLO_H_!!class CHello {! public:! int doit();!};! !!#endif!



www.h-da.de


h_da

What if …

• we have to support different platforms using different compilers?

• we have to define certain parameters for different platforms and build variants? (i.e. debug, release, unit test etc.)

• we have to make use of different libraries for different platforms and build variants?

• we have a project with 20K lines of code (LOC) spread over 300 source files?

We may run into trouble documenting this within

a README file - interpreted by humans :-)



www.h-da.de


h_da

Automate!!

• Shell Script • GNU make

• Apache ant • Perforce jam • cmake • etc.

Define „what to do“ using a

formal description that is

parsed, interpreted and

executed automatically.

!

If you wan’t to change the way

the SW is built, just change

the „description“.



www.h-da.de


h_da

The Pragmatic Solution: A Shell Script

#!/bin/sh!# FILE: buildit.sh!# DESC: build script - HelloES !g++ -o helloES main.cpp CHello.cpp

shell>> ./buildit.sh

No README needed anymore :-)

• What about dependencies? • How to avoid build of already available

artifacts? • How to realize a parallel build?



www.h-da.de


h_da

GNU make

!

• Probably THE TOOL to automate builds while managing dependencies and parallelization.

• The creation is described using „Makefiles“. • A Makefile contains the following

‣ any number „recipes“ (or rules), identified by a „target“(a target may correspond to a filename)

‣ each target may have prerequisites (files or other targets)

‣ each target may define a action !

# comment !VAR=value !target: prerequisites action



www.h-da.de


h_da

make „HelloES“ - a first attempt

# DESC: build recipe no. 1 - HelloES !!# build the executable!build: CHello.h main.cpp CHello.cpp!! g++ -o helloES main.cpp CHello.cpp!!# remove all auto-generated artifacts!clean:!! rm -f helloES!

shell>> make (….or „shell>> make build“)

No README needed anymore :-)



www.h-da.de


h_da

GNU make provides even more

• Definition and modification of variables. • Conditions (if, else etc.) • Escape to shell scripting. • Generic rules to build similar stuff. • Available for most host platforms.

(incl. MS Windows)



www.h-da.de


h_da

GNU make : Internal Macros

$@ # name of the target which was called $? # all dependencies newer then the target !$^ # all dependencies without duplicates !$+ # all dependencies with duplicates $< # the first dependence % # can be used as a wildcard target name.!

• a.k.a. automatic variables. • Support the definition of generic rules. • Help to shorten the makefiles. • Introduce complexity for unexperienced

developers.



www.h-da.de


h_da

make „HelloES“ - a second attempt# DESC: build recipe no. 2 - HelloES !PROG = helloES!CFLAGS = -Wall -pedantic!CXX = g++!SRC_FILES := $(wildcard *.cpp)!HDR_FILES := $(wildcard *.h)!OBJS := $(patsubst %.cpp, %.o, $(SRC_FILES))!!# link the executable!$(PROG): $(OBJS)!! $(CXX) -o $@ $^!!# compile the object files!%.o: %.cpp $(HDR_FILES)!! $(CXX) $(CFLAGS) -c $< -o $@!!clean:!! rm -f $(OBJS) $(PROG)shell>> make -j2 (for parallelization)

additional files are included automatically

headers are added as dependency for all cpp files



www.h-da.de


h_da

GNU make : Makefile further …

• … can include other Makefiles. • … can delegate processing to other Makefiles.

(e.g. build within a subdirectory examples, libs etc.) • … can receive arguments.

(e.g. to be handled using conditional variables) • … are integrated into most IDEs. • … can also be used for non-SW projects.

(e.g. LaTeX document creation, command-line based image processing etc.)

Basically to formalize processing files

while maintaining dependencies and

support parallelization.



www.h-da.de


h_da

Apache ANT

• Aimed for Java projects • Description uses XML format.

<project name="HelloES" default="build" basedir=".">!<description>build recipe no. 3 - HelloES</description>!<target name="init">! <property name="prog" value="helloES"/>! <property name="source" value="main.cpp CHello.cpp"/>!</target>!<target name="build" depends="init">! <exec dir="." executable="g++"> ! <arg line="-o ${prog}"/> ! <arg line="${source}"/> ! </exec>!</target>!<target name="clean" depends="init">!! <delete file="${prog}"/>!</target>!</project>



www.h-da.de


h_da

!Autotools a.k.a the „GNU Build System“

• A complete toolchain to provide an automated build of software, based upon GNU Make.

• Improves portability of the build process: allows to define generic build instructions with dependencies which are adapted to the actual build environment.

• Allows to build the software with or without certain optional modules due to configuration.

• It allows cross-platform compilation. • State of the art in the open-source community. !



www.h-da.de


h_da

!Why not Autotools?

• It’s easy to use, but can be complex to setup. • The initial configuration is written using a

macro script language „m4“. • Autotools create a bash-script out of this

initial configuration, which is very large (to ensure portability) and therefore is not easy to understand or debug.

• This bash-script checks and evaluates the actual environment and creates a makefile structure, which are easily >50k loc.

!



www.h-da.de


h_da

!Autotools Example

AC_INIT(helloES, 0.1)!AM_INIT_AUTOMAKE!AC_PROG_CXX!AC_CONFIG_HEADERS([config.h])!AC_CONFIG_FILES([Makefile]) !AC_OUTPUT

!!shell>> touch NEWS README AUTHORS ChangeLogshell>> autoreconf --install # create scripts shell>> ./configure # eval system & create Makefile(s) shell>> make # build application shell>> make install # install application locally shell>> make distcheck # create tar ball !!

bin_PROGRAMS = helloES!helloES_SOURCES = main.cpp CHello.cpp CHello.h

configure.ac

Makefile.am



www.h-da.de


h_da

!CMake

• Cross-Platform Toolchain to provide an automated SW build.

• Available for many platforms and IDEs (it’s even able to create IDE project files).

• Easier to setup (compared to e.g. Autotools). • Allows to change build directories (out-of-

source build) to build different releases into different target directories.

• Provides an interface to define (unit-)tests. • Generates GNU Makefiles. !



www.h-da.de


h_da

!CMake Example

cmake_minimum_required(VERSION 2.6)!project (helloES)!add_executable(helloES main.cpp CHello.cpp CHello.h)!install (TARGETS helloES DESTINATION bin)!

enable_testing()!

add_test (MySimpleTest helloES)!set_tests_properties (MySimpleTest ! PROPERTIES PASS_REGULAR_EXPRESSION "Hello ES“)!

set(CPACK_SOURCE_GENERATOR "TGZ")!include (CPack)

!!shell>> cmake . # eval. system & gen. Makefile(s) shell>> make # build application shell>> make test # run tests shell>> make install # install application locally shell>> make package_source # create tarball !!!

CMakeLists.txt

For our example the src-dir is also the project root.

That will cause some problems.




h_da

Build Optimization

Adapt it to the target.




www.h-da.de


h_da

Step One: Measure• Systemlog

e.g. Linux Kernel Messages „dmesg“ !

• Kernel Tracese.g. QNX Kernel Trace, LTTng !

• Instrumented Codee.g. Logfiles, LTTng

"... premature optimization

is the root of all evil ..." (Donald E. Knuth 1974)



www.h-da.de


h_da

Identify the low hanging fruits

• Know your hardware platform.e.g. CPU features (FPU, SSSE3 etc.)

• Know your software’s dependencies. e.g. libraries, other executables

• Know your tools.e.g. compiler (optimization for speed, size, CPU)

• Know how to measuree.g. log and trace

• Know your software’s algorithms e.g. heavy use of floating-point arithmetic



www.h-da.de


h_da

How to get information about you HW

• Read the TRM (Technical Reference Manual) e.g. CPU features (FPU, SSSE3 etc.)

• Use your OSe.g. „cat /proc/cpuinfo“ on Linux@Intel Galileoprocessor! ! : 0!vendor_id! ! : GenuineIntel!(...)!model name! ! : 05/09!cpu MHz! ! : 399.076!cache size! ! : 0 KB!(...)!fpu! ! : yes!fpu_exception! : yes!cpuid level!! : 7!wp! ! : yes!flags! ! : fpu vme pse tsc msr pae cx8 apic pge pbe nx smep!bogomips! ! : 798.15!clflush size! ! : 32!cache_alignment! : 32!address sizes! : 32 bits physical, 32 bits virtual



www.h-da.de


h_da

How to analyze SW dependecies• Read the Code search for include statements („grep“) search your Makefiles („grep“) => time consuming and inaccurate • Use the linker !

!

!

!

• Use CMake with graphviz

linux-vdso.so.1!libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6!/lib64/ld-linux-x86-64.so.2

shell>> ldd helloES (works also for libs)

shell>> cmake --graphviz=deps.dot . # build shell>> dot -Tpng -odeps.png deps.dot



www.h-da.de


h_da

Know your Tools• Use compiler optimization features

gcc: (check also „gcc -Q --help=optimizers“) -O0 ! default: no optimization -O1 ! optimize (equals to „-O“) -O1 ! optimize even more -O3 ! optimize yet more -Os ! optimize for size -Ofast!optimize for execution time -Og ! optimize debugging experience

• Use platform specific options gcc -mtune=<cputype> -march=<cputype>

!!

check gcc’s man pages and other platform specific „-m“ options




h_da

References

[Holzmann, 2006] Holzmann, G.J.: The Power of 10: Rules for Developing Safety-Critical Code. IEEE Computer, Volume 39, Issue 6, 2006. [Hunt and Thomas, 1999] Hunt, A. and Thomas, D.: The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley, 1999. [Meyers, 2005] Meyers, S.: Effective C++, 3rd ed., Addison-Wesley, 2005. [Pilone and Miles, 2008] Pilone, D. and Miles, R.: Head First Software Development. O’Reilly, 2008 [Wietzke and Tran, 2005] Wietzke, J. and Tran, M. T.: Automotive Embedded Systeme. Springer, 2005.


Building Embedded Systems - fbi · icm In-Car Multimedia Labs ! Hochschule Darmstadt IN-CAR...

Documents

Transcript of Building Embedded Systems - fbi · icm In-Car Multimedia Labs ! Hochschule Darmstadt IN-CAR...