15-10-2012, 01:49 PM
Embedded systems programming
Embedded systems.ppt (Size: 1.14 MB / Downloads: 52)
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.
Overview
Embedded systems
What’s special/different
predictability
Resource management
memory
Access to hardware
Absolute addresses
Bits – unsigned
Coding standards
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 doesn’t
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 – you’ll know to do this or only work on web applications (and the like)
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 that’ll 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 wouldn’t fly in a plane that used those
In 5 years, we’ll have solved the problem for throw
Each individual throw is predictable
Not just in C++ programs
Similar operations in other languages are similarly avoided
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
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 can’t/don’t notice problems themselves
Embedded systems.ppt (Size: 1.14 MB / Downloads: 52)
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.
Overview
Embedded systems
What’s special/different
predictability
Resource management
memory
Access to hardware
Absolute addresses
Bits – unsigned
Coding standards
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 doesn’t
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 – you’ll know to do this or only work on web applications (and the like)
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 that’ll 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 wouldn’t fly in a plane that used those
In 5 years, we’ll have solved the problem for throw
Each individual throw is predictable
Not just in C++ programs
Similar operations in other languages are similarly avoided
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
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 can’t/don’t notice problems themselves