Download Embedded Electronics

Document related concepts

Industry Standard Architecture wikipedia , lookup

Airborne Networking wikipedia , lookup

Low Pin Count wikipedia , lookup

Distributed operating system wikipedia , lookup

MIL-STD-1553 wikipedia , lookup

VMEbus wikipedia , lookup

Bus (computing) wikipedia , lookup

CAN bus wikipedia , lookup

Transcript
Embedded Electronics
Large to small…
Systems
By Peter Faber, April/May 2015
Embedded Systems
•
Invisible computers, inside most of the devices
we use, from a music player, a mobile phone, to
cars, trains, medical equipment, and so on.
• an embedded system special-purpose computer
system, part of a larger system which it controls
•
More than humans on the planet, already
–
•
99% of processors used in embedded systems
–
•
40 billion of such devices by 2020
4 billion embedded processors sold last year
€71 billion global market in 2009, growth of
14%
–
Market size is about 100 times the desktop
market
Embedded systems are everywhere
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o oo
o
o
o
oo
o
Our daily lives depend on embedded systems
From your bathroom...
Product: Sonicare Plus toothbrush.
Microprocessor: 8-bit Zilog Z8.
To Mars...
• Product:
NASA's Mars
Sojourner
Rover.
Microprocess
or:
8-bit Intel
Big...
And small...
Characteristics of embedded systems
•
Single-functioned
–
•
Dedicated to perform a single function
Complex functionality
–
Often have to run sophisticated algorithms or multiple algorithms.
•
•
Tightly-constrained
–
•
Low cost, low power, small, fast, etc.
Reactive and real-time
–
–
•
Cell phone, laser printer.
Continually reacts to changes in the system’s environment
Must compute certain results in real-time without delay
Safety-critical
–
Must not endanger human life and the environment
Level of dependency
Embedded systems:
90% future innovations
40% price
Electronic Injections
Check Control
Speed Control
Central Locking
…
Electronic Gear Control
Electronic Air Condition
ASC Anti Slip Control
ABS
Telephone
Seat Heating Control
Autom. Mirror Dimming
…
1970
1980
Navigation System
CD-Changer
ACC Adaptive Cruise
Control
Airbags
DSC Dynamic Stability
Control
Adaptive Gear Control
Xenon Light
BMW Assist
RDS/TMC
Speech Recognition
Emergency Call…
ACC Stop&Go
BFD
ALC
KSG
42 voltage
Internet Portal
GPRS, UMTS
Telematics
Online Services
BlueTooth
Car Office
Local Hazard Warning
Integrated Safety
System
Steer/Brake-By-Wire
I-Drive
Lane Keeping Assist.
Personalization
Software Update
Force Feedback Pedal…
1990
2000
source: BMW
Automotive Electronics
Automotive architecture example
Evolution of handsets and technology
Smartphone architecture example
Battery
RF
Baseband
ASIC
64MB
NOR
FLASH
64MB
SDRAM
2MPix
camera
module
LED
Flash
Keyboar
d
512MB
NAND
FLASH
512 MB
DDR
DRAM
Position
sensors
Charger
Energy
managemen
t ASIC
White LED
driver
ARM9
Back-light
LEDs
MixedSignal
ASIC
UMA core
SIM
IH
F
BT
Module
Application
processor
MM
C
ARM9
Frame
buffer
ASIC
UMA core
LCDs
Architectures: Networked embedded systems
Distributed
functionality
...
Distributed
across
networks
Several
functions
per processor
...
Application areas: critical vs. best-effort
•
Critical (e.g., avionics)
–
–
–
–
–
•
Best effort (e.g., multimedia, networks)
–
–
–
–
–
•
Based on worst-case assumptions
Static reservation of resources
Schedulability analysis and static scheduling
Simple execution platforms
Leads to overdesign (underutilization)
Based on average-case
Dynamic reservation of resources
Sophisticated architectures
Adaptive scheduling mechanisms
Leads to temporary unavailability
Bridging the gap: partitioned architectures
Graphical illustration of Moore’s law
1981
1984
1987
1990
1993
1996
1999
2002
10,000
transistors
150,000,000
transistors
Leading edge
chip in 1981
Leading edge
chip in 2002
• Something that doubles frequently grows
more quickly
than most people realize!
– A 2002 chip could hold about 15,000 1981
chips inside itself
More Moore vs. More than Moore
Tubes to Chips: Integrated Circuits
• Driven by Information
Processing needs
IBM Power 5 IC
(2004)
IBM 701 calculator (1952)
Slide soruce: Krish Chakrabarty, Duke University
Tubes to Chips: Biochips
• Driven by biomolecular analysis
needs
Agilent DNA analysis
Lab on a Chip (1997)
Test tube analysis
Slide soruce: Krish Chakrabarty, Duke University
Tubes to Chips: Biochips, cont.
Test tubes
Automation
Integration
Miniaturization
Robotics
Microfluidics
Slide soruce: Krish Chakrabarty, Duke University
Automation
Integration
Miniaturization
Automation
Integration
Miniaturization
Biochip Architecture
Slide soruce: Krish Chakrabarty, Duke University
Embedded systems design problem
– Find an implementation that can perform the computation such that the requirements are satisfied.
• Embedded systems perform computations (software) that are subject
to physical constraints (hardware)
–Reaction to a physical environment: deadline, throughput, jitter
–Execution on a physical platform: processor speed, power, reliability
• The need for an embedded systems design discipline
–Computer science separates computation from physical constraints
–Computer engineering ignores computation
Traditional embedded systems
design
• Design and build
the target hardware
• Develop the software
independently
• Integrate them and
hope it works
Does not work for complex systems !!!!
Embedded software: size and deployment
Embedded software: complexity growth
Increasing complexity (telecom example)
Design crisis
Log Scale
Gates/cm2
Moore’s Law
Widening
Gap
Design Productivity
Software Productivity
0.35µ
0.25µ
0.18µ
0.15µ 0.12µ
Technology (micron)
0.1µ
We need a better design
methodology
•
Design methodology: the process of creating a system
–
Goal: optimize competing design metrics
•
•
•
•
•
Design flow: sequence of steps in a design methodology.
–
–
•
Time-to-market
Design cost
Manufacturing cost
Quality, etc.
May be partially or fully automated.
Use tools to transform, verify design.
Design flow is one component of design methodology.
Methodology also includes management, organization, etc.
Abstraction and clustering
IP Block Performance
Inter IP Communication Performance Models
Gate Level Model
Capacity Load
abstract
1970’s
abstract
RTL
cluster
RTL
Clusters
SW
Models
cluster
abstract
Transistor Model
Capacity Load
abstract
SDF
Wire Load
IP Blocks
cluster
1980’s
1990’s
Year 2000 +
Abstraction and clustering: Platforms
•
The “PC platform” makes development easier
– x86 instruction-set architecture
– fully specified set of buses and
– a specified set of I/O devices
•
Similar platform definitions for specific embedded systems application
areas
Platform API
Application Software
Software
Software Platform
Hardware Platform
Input devices
Output Devices
Hardware
I
O
Network
System-level design
Application
model
System platform
model
Application
model
Architecture
model
System-level
design tasks
Constructive vs.
improvement
Model of system
implementation
Software
synthesis
Hardware
synthesis
Evaluation
Analysis vs.
simulation
Typical design tasks: Mapping and
scheduling
Given
–
–
–
P1
P2
Application: set of interacting processes
Platform: set of nodes
Timing constraints: deadlines
m3
N1
Determine
–
–
m1
m2
P3
P4
m4
N2
Mapping of processes and messages
Schedule tables for processes and messages
•
Such that the timing constraints are satisfied
P1
N1
Schedule
table
P4
P2
N2
Bus
S2
S1
m1
P3
m2
m3
m4
Deadline
Biochips design tasks
Source
Binding
Allocation
In S 2
Operation Area (cells) Time (s)
Mixing
2x2
6
Mixing
2x3
5
Mixing
2x4
4
Dilution
2x2
6
Dilution
2x3
5
Dilution
2x4
3
Storage
1x1
–
In S 1
1
In R 1
2
5
Dilute
S1
Mixer1
Detect
4
Detect
R1
Mixer2
Diluter
Mixer2
Store
S2
O9
Mixer1
R2
W Detector
9
Mix
B
Diluter
S3
In R 2
3
Scheduling
O7
O3
Store
O11
Detector
O10
O4
6
7
Mix
Sink
Placement
In B
10
8
Design-space exploration
Safety-Critical Systems
•
Safety is a property of a system that
will not endanger human life
or the environment.
•
A safety-related system is one by
which the safety of the equipment or
plant is ensured.
•
Safety-critical system is:
–
–
Safety-related system, or
High-integrity system
Our daily lives depend on embedded systems
Introduction to
CANBUS
36
Presentation Goals
1. CANBUS Introduction




What is CANBUS?
Who uses CANBUS?
CANBUS history
CANBUS timeline
2. CANBUS Characteristics



OSI Model
Physical Layer
Transmission Characteristics
3. Message Oriented Communication
4. Message Format
5. Bus Arbitration
37
What is CANBUS?
CANBUS or CAN bus – Controller Area Network bus
An automotive serial bus system developed to satisfy
the following requirements:

Network multiple microcontrollers with 1 pair of wires.

Allow microcontrollers communicate with each other.

High speed, real-time communication.

Provide noise immunity in an electrically noisy
environment.

Low cost
38
Who uses CANBUS?
•
•
Designed specifically for automotive applications
Today - industrial automation / medical equipment
CANBUS Market Distribution
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
Automotive
Medical / Industrial
Markets
39
CANBUS History
•
•
•
First idea - The idea of CAN was first conceived
by engineers at Robert Bosch Gmbh in Germany
in the early 1980s.
Early focus - develop a communication system
between a number of ECUs (electronic control
units).
New standard - none of the communication
protocols at that time met the specific
requirements for speed and reliability so the
engineers developed their own standard.
40
CANBUS Timeline
•
1983 : First CANBUS project at Bosch
•
1986 : CAN protocol introduced
•
1987 : First CAN controller chips sold
•
1991 : CAN 2.0A specification published
•
1992 : Mercedes-Benz used CAN network
•
1993 : ISO 11898 standard
•
1995 : ISO 11898 amendment
•
Present : The majority of vehicles use CAN bus.
41
CANBUS and the OSI Model
•
CAN is a closed network
– – no need for security, sessions or logins.
– - no user interface requirements.
•
Physical and Data Link layers in silicon.
42
CANBUS Physical Layer



Physical medium – two wires terminated at both ends by resistors.
Differential signal - better noise immunity.
Benefits:
 Reduced weight, Reduced cost
 Fewer wires = Increased reliability
Conventional multi-wire looms
CAN bus network
vs.
http://canbuskit.com/what.php
43
Transmission Characteristics




Up to 1 Mbit/sec.
Common baud rates: 1 MHz, 500 KHz and 125 KHz
All nodes – same baud rate
Max length:120’ to 15000’ (rate dependent)
© esd electronics, Inc. • 525 Bernardston Road • Greenfield, MA 01301
44
Message Oriented Transmission Protocol
•
•
•
•
•
Each node – receiver & transmitter
A sender of information transmits to all devices on the bus
All nodes read message, then decide if it is relevant to them
All nodes verify reception was error-free
All nodes acknowledge reception
CAN bus
© 2005 Microchip Technology Incorporated. All Rights Reserved.
45
Message Format
•
•
•
Each message has an ID, Data and overhead.
Data –8 bytes max
Overhead – start, end, CRC, ACK
46
Example of Message Transaction
47
Bus Arbitration
•
•
•
•
Arbitration – needed when multiple nodes try to transmit at
the same time
Only one transmitter is allowed to transmit at a time.
A node waits for bus to become idle
Nodes with more important messages continue transmitting
CAN bus
© 2005 Microchip Technology Incorporated. All Rights Reserved.
48
Bus Arbitration
•
•
•
•
Message importance is encoded in message ID.
Lower value = More important
As a node transmits each bit, it verifies that it sees
the same bit value on the bus that it transmitted.
A “0” on the bus wins over a “1” on the bus.
Losing node stops transmitting, winner continues.
49
Summary
• CAN bus – Controller Area Network bus
• Primarily used for building ECU networks in
automotive applications.
• Two wires
• OSI - Physical and Data link layers
• Differential signal - noise immunity
• 1Mbit/s, 120’
• Messages contain up to 8 bytes of data
50
Bus arbitration
A “0” (low voltage) on the bus by 1 node
wins over a “1” (high voltage) on the bus.
51
Bus Arbitration Flowchart
52
Test Your system is working up against the main ECU (my CAN system).
You’ll now figure out and program the following:
Each group will program their own ECU, to be placed somewhere in ”the car”.
Group 1 Marius & Jonathan: Dashboard ECU
Group 2 Narcis & Niroy:
Engine ECU
Group 3 Martin & Georgi:
Tyre System ECU
Group 1 Program a system that asks the engine for temperature and the Tyre System for pressure
And accepts emergency messages from both
Group 2 Program a system that sends temeratures on request and alarm for overheating
Group 3 Program a system that sends tyre pressure on request and alarm for very low pressure