Chapter 25 Embedded systems programming

1
Chapter 25Embedded systems programming

• Bjarne Stroustrup
• www.stroustrup.com/Programming

2
Abstract

• This lecture provides a brief overview of what
  distinguishes embedded systems programming from
  ordinary programming. It then touches upon
  facilities that become prominent or problems when
  working close to the hardware such as free
  store use, bit manipulation, and coding
  standards. Remember not all computers are
  little grey boxes hiding under desks in offices.

3
Overview

• Embedded systems
• Whats special/different
• predictability
• Resource management
• memory
• Access to hardware
• Absolute addresses
• Bits unsigned
• Coding standards

4
Embedded systems

• Hard real time
• Response must occur before the deadline
• Soft real time
• Response should occur before the deadline most of
  the time
• Often there are plenty of resources to handle the
  common cases
• But crises happen and must be handled
• Predictability is key
• Correctness is even more important than usual
• correctness is not an abstract concept
• but I assumed that the hardware worked
  correctly is no excuse
• Over a long time and over a large range of
  conditions, it simply doesnt

5
Embedded systems

• Computers used as part of a larger system
• That usually doesnt look like a computer
• That usually controls physical devices
• Often reliability is critical
• Critical as in if the system fails someone
  might die
• Often resources (memory, processor capacity) are
  limited
• Often real-time response is essential

6
Embedded systems

• What are we talking about?
• Assembly line quality monitors
• Bar code readers
• Bread machines
• Cameras
• Car assembly robots
• Cell phones
• Centrifuge controllers
• CD players
• Disk drive controllers
• Smart card processors

• Fuel injector controls
• Medical equipment monitors
• PDAs
• Printer controllers
• Sound systems
• Rice cookers
• Telephone switches
• Water pump controllers
• Welding machines
• Windmills
• Wrist watches

7
Do You Need to Know This Stuff ?

• Computer Engineers You will build and oversee
  the building of these systems
• All close to he hardware code resembles this
• The concern for correctness and predictability of
  embedded systems code is simply a more critical
  form of what we want for all code
• Electrical Engineers You will build and oversee
  the building of these systems.
• You have to work with the computer guys
• You have to be able to talk to them
• You may have to teach them
• You may have to take over for them
• Computer scientists youll know to do this or
  only work on web applications (and the like)

8
Predictability

• C operations execute in constant, measurable
  time
• E.g., you can simply measure the time for an add
  operation or a virtual function call and thatll
  be the cost of every such add operation and every
  virtual function call (pipelining, caching,
  implicit concurrency makes this somewhat trickier
  on some modern processors)
• With the exception of
• Free store allocation (new)
• Exception throw
• So throw and new are typically banned in hard
  real-time applications
• Today, I wouldnt fly in a plane that used those
• In 5 years, well have solved the problem for
  throw
• Each individual throw is predictable
• Not just in C programs
• Similar operations in other languages are
  similarly avoided

9
Ideals/aims

• Given the constraints
• Keep the highest level of abstraction
• Dont write glorified assembler code
• Represent your ideas directly in code
• As always, try to write the clearest, cleanest,
  most maintainable code
• Dont optimize until you have to
• People far too often optimize prematurely
• John Bentley's rules for optimization
• First law Dont do it
• Second law (for experts only) Dont do it yet

10
Embedded systems programming

• You (usually) have to be much more aware of the
  resources consumed in embedded systems
  programming than you have to in ordinary
  programs
• Time
• Space
• Communication channels
• Files
• ROM (Read-Only Memory)
• Flash memory
• You must take the time to learn about the way
  your language features are implemented for a
  particular platform
• Hardware
• Operating system
• Libraries

11
Embedded systems programming

• A lot of this kind of programming is
• Looking at specialized features of an RTOS (Real
  Time Operating System)
• Using a Non-hosted environment (thats one way
  of saying a language right on top of hardware
  without an operating system)
• Involving (sometimes complex) device driver
  architectures
• Dealing directly with hardware device interfaces
• We wont go into details here
• Thats what specific courses and manuals are for

12
How to live without new
old object
Free space
old object

• Whats the problem
• C code refers directly to memory
• Once allocated, an object cannot be moved (or can
  it?)
• Allocation delays
• The effort needed to find a new free chunk of
  memory of a given size depends on what has
  already been allocated
• Fragmentation
• If you have a hole (free space) of size N and
  you allocate an object of size M where MltN in it,
  you now have a fragment of size N-M to deal with
• After a while, such fragments constitute much of
  the memory

New object
13
How to live without new

• Solution pre-allocate
• Global objects
• Allocated at startup time
• Sets aside a fixed amount of memory
• Stacks
• Grow and shrink only at the top
• No fragmentation
• Constant time operations
• Pools of fixed sized objects
• We can allocate and deallocate
• No fragmentation
• Constant time operations

Stack
Top of stack
Pool
14
How to live without new

• No new (of course)
• And no malloc() (memory allocation during
  runtime) either (for those of you who speak C)
• No standard library containers (they use free
  store indirectly)
• Instead
• Define (or borrow) fixed-sized Pools
• Define (or borrow) fixed-sized Stacks
• Do not regress to using arrays and lots of
  pointers

15
Pool example

• // Note element type known at compile time
• // allocation times are completely predictable
  (and short)
• // the user has to pre-calculate the maximum
  number of elements needed
• templateltclass T, int Ngtclass Pool
• public
• Pool() // make pool of N Ts construct pools
  only during startup
• T get() // get a T from the pool return 0 if
  no free Ts
• void free(T) // return a T given out by get()
  to the pool
• private
• // keep track of TN array (e.g., a list of
  free objects)
• PoolltSmall_buffer,10gt sb_pool
• PoolltStatus_indicator,200gt indicator_pool

16
Stack example

• // Note allocation times completely predictable
  (and short)
• // the user has to pre-calculate the maximum
  number of elements needed
• templateltint Ngtclass Stack
• public
• Stack() // make an N byte stack construct
  stacks only during startup
• void get(int N) // allocate n bytes from the
  stack return 0 if no free space
• void free(void p) // return the last block
  returned by get() to the stack
• private
• // keep track of an array of N bytes (e.g. a top
  of stack pointer)
• Stacklt501024gt my_free_store // 50K worth of
  storage to be used as a stack
• void pv1 my_free_store.get(1024)
• int pi static_castltintgt(pv1) // you have to
  convert memory to objects
• void pv2 my_free_store.get(50)
• Pump_driver pdriver static_castltPump_drivergt(p
  v2)

17
Templates

• Excellent for embedded systems work
• No runtime overhead for inline operations
• Sometimes performance matters
• No memory used for unused operations
• In embedded systems memory is often critical
  (limited)

18
How to live with failing hardware

• Failing how?
• In general, we cannot know
• In practice, we can assume that some kinds of
  errors are more common than others
• But sometimes a memory bit just decides to change
• Why?
• Power surges/failure
• The connector vibrated out of its socket
• Falling debris
• Falling computer
• X-rays
• Transient errors are the worst
• E.g., only when the temperature exceeds 100 F.
  and the cabinet door is closed
• Errors that occur away from the lab are the worst
• E.g., on Mars

19
How to live with failing hardware

• Replicate
• In emergency, use a spare
• Self-check
• Know when the program (or hardware) is
  misbehaving
• Have a quick way out of misbehaving code
• Make systems modular
• Have some other module, computer, part of the
  system responsible for serious errors
• In the end, maybe a person i.e., manual override
  
• Remember HAL ?
• Monitor (sub)systems
• In case they cant/dont notice problems
  themselves

20
Absolute addresses

• Physical resources (e.g., control registers for
  external devices) and their most basic software
  controls typically exist at specific addresses in
  a low-level system
• We have to enter such addresses into our programs
  and give a type to such data
• For example
• Device_driver p reinterpret_castltDevice_driver
  gt(0xffb8)
• Serial_port_base COM1 reinterpret_castltSerial_p
  ort_basegt(0x3f8)

21
Bit manipulation Unsigned integers

• How do you represent a set of bits in C?
• unsigned char uc // 8 bits
• unsigned short us // typically 16 bits
• unsigned int ui // typically 16 bits or 32
  bits // (check before using) // many
  embedded systems have 16-bit ints
• unsigned long int ul // typically 32 bits or 64
  bits
• stdvectorltboolgt vb(93) // 93 bits
• Use only if you really need more than 32 bits
• stdbitset bs(314) // 314 bits
• Use only if you really need more than 32 bits
• Typically efficient for multiples of sizeof(int)

22
Bit manipulation
0
1
0
0
1
0
1
1
0xaa
a
b

• and
• inclusive or
• exclusive or
• ltlt left shift
• gtgt right shift
• ones complement

0
0
0
1
1
1
1
0
0x0f
0x0a
ab
0
0
0
0
1
0
1
0
0xaf
ab
0
1
0
1
1
1
1
1
0xa5
ab
0
1
0
1
0
1
0
1
0x54
altlt1
1
0
1
0
0
1
0
0
0x03
bgtgt2
0
0
0
1
1
0
0
0
0xf0
b
1
1
1
0
0
0
0
1
23
Bit manipulation
Sign bit

• Bitwise operations
• (and)
• (or)
• (exclusive or xor)
• ltlt (left shift)
• gtgt (right shift)
• (one's complement)
• Basically, what the hardware provides
  right
• For example
• void f(unsigned short val) // assume 16-bit,
  2-byte short integer
• unsigned char right val 0xff // rightmost
  (least significant) byte
• unsigned char left (valgtgt8) 0xff //
  leftmost (most significant) byte
• bool negative val 0x8000 // sign bit (if
  2s complement)
• //

8 bits 1 byte
val
1
1
0
0
1
0
1
0
1
1
0
0
1
1
0
0
0xff
1
1
1
1
1
1
1
1
1
0
0
1
0
0
1
1
false
true
24
Bit manipulation

• Or
• Set a bit
• And
• Is a bit set? Select (mask) some bits
• For example
• enum Flags bit41ltlt4, bit31ltlt3, bit21ltlt2,
  bit11ltlt1, bit01
• unsigned char x bit3 bit1 // x becomes 82
• x bit2 // x becomes 842
• if (xbit3) // is bit3 set? (yes, it is)
• //
• unsigned char y x (bit4bit2) // y becomes 4
• Flags z Flags(bit2bit0) // the cast is
  necessary because the compiler
• // doesnt know that 5 is in the
  Flags range

0xff
1
1
1
1
1
1
1
1
val
0
1
1
1
1
0
0
0
25
Bit manipulation

• Exclusive or (xor)
• ab means (ab) !(ab) either a or b but not
  both
• unsigned char a 0xaa
• unsigned char b 0x0f
• unsigned char c ab
• Immensely important in graphics and cryptography

0
1
0
0
1
0
1
1
0xaa
a
b
0
0
0
1
1
1
1
0
0x0f
0xa5
ab
0
1
0
1
0
1
0
1
26
Unsigned integers

• You can do ordinary arithmetic on unsigned
  integers
• Avoid that when you can
• Try never to use unsigned just to get another bit
  of precision
• If you need one extra bit, soon, youll need
  another
• Dont mix signed and unsigned in an expression
• You cant completely avoid unsigned arithmetic
• Indexing into standard library containers uses
  unsigned(in my opinion, thats a design error)
• vectorltintgt v
• //
• for (int i 0 iltv.size() i)
• for (vectorltintgtsize_type i 0 iltv.size()
  i)
• for (vectorltintgtiterator p v.begin()
  p!v.end() p)

signed
unsigned
correct, but pedantic
Yet another way
27
Complexity

• One source of errors is complicated problems
• Inherent complexity
• Another source of errors is poorly-written code
• Incidental complexity
• Reasons for unnecessarily complicated code
• Overly clever programmers
• Who use features they dont understand
• Undereducated programmers
• Who dont use the most appropriate features
• Large variations in programming style

28
Coding standards

• A coding standard is a set of rules for what code
  should look like
• Typically specifying naming and indentation rules
• E.g., use Stroustrup layout
• Typically specifying a subset of a language
• E.g., dont use new or throw to avoid
  predictability problems
• Typically specifying rules for commenting
• Every function must have a comment explaining
  what it does
• Often requiring the use of certain libraries
• E.g., use ltiostreamgt rather than ltstdio.hgt to
  avoid safety problems
• Organizations often try to manage complexity
  through coding standards
• Often they fail and create more complexity than
  they manage

29
Coding standards

• A good coding standard is better than no standard
• I wouldnt start a major (multi-person,
  multi-year) industrial project without one
• A poor coding standard can be worse than no
  standard
• C coding standards that restrict programming to
  something like the C subset do harm
• They are not uncommon
• All coding standards are disliked by programmers
• Even the good ones
• All programmers want to write their code exactly
  their own way
• A good coding standard is prescriptive as well as
  restrictive
• Here is a good way of doing things as well as
• Never do this
• A good coding standard gives rationales for its
  rules
• And examples

30
Coding standards

• Common aims
• Reliability
• Portability
• Maintainability
• Testability
• Reusability
• Extensibility
• Readability

31
Some sample rules

• No function shall have more than 200 lines (30
  would be even better)
• that is, 200 non-comment source lines
• Each new statement starts on a new line
• E.g., int a 7 x a7 f(x,9) // violation!
• No macros shall be used except for source control
• using ifdef and ifndef
• Identifiers should be given descriptive names
• May contain common abbreviations and acronyms
• When used conventionally, x, y, i, j, etc., are
  descriptive
• Use the number_of_elements style rather than the
  numberOfElements style
• Type names and constants start with a capital
  letter
• E.g., Device_driver and Buffer_pool
• Identifiers shall not differ only by case
• E.g., Head and head // violation!

32
Some more sample rules

• Identifiers in an inner scope should not be
  identical to identifiers in an outer scope
• E.g., int var 9 int var 7 var //
  violation var hides var
• Declarations shall be declared in the smallest
  possible scope
• Variables shall be initialized
• E.g., int var // violation var is not
  initialized
• Casts should be used only when essential
• Code should not depend on precedence rules below
  the level of arithmetic expressions
• E.g., x abc // ok
• if( altb cltd) // violation parenthesize (altb)
  and (cltd)
• Increment and decrement operations shall not be
  used as subexpressions
• E.g., int x vi // violation (that
  increment might be overlooked)

33
An example of bit manipulation

• The Tiny Encryption Algorithm (TEA)
• Originally by David Wheeler
• http//143.53.36.2358080/tea.htm
• Dont look too hard at the code (unless you
  happen to need a good simple encryption algorithm
  for an application) its simply to give you the
  flavor of some bit manipulation code
• It takes one word (4 bytes at a time)
• E.g., 4 characters from a string or an image file
• It assumes 4-byte long integers
• Explanation is at the link (and in the book)
• Without the explanation this is just an example
  of how bit manipulation code can look. This code
  is not meant to be self-explanatory.

34
TEA

• void encipher(
• const unsigned long const v,
• unsigned long const w,
• const unsigned long const k)
• unsigned long y v0
• unsigned long z v1
• unsigned long sum 0
• unsigned long delta 0x9E3779B9
• unsigned long n 32
• while(n--gt0)
• y (z ltlt 4 z gtgt 5) z sum ksum3
• sum delta
• z (y ltlt 4 y gtgt 5) y sum ksumgtgt11
  3
• w0y
• w1z

35
TEA

• void decipher(
• const unsigned long const v,
• unsigned long const w,
• const unsigned long const k)
• unsigned long y v0
• unsigned long z v1
• unsigned long sum 0xC6EF3720
• unsigned long delta 0x9E3779B9
• unsigned long n 32
• // sum deltaltlt5 in general, sum delta n
• while(n--gt0)
• z - (y ltlt 4 y gtgt 5) y sum ksumgtgt11
  3
• sum - delta
• y - (z ltlt 4 z gtgt 5) z sum ksum3
• w0y
• w1z