real-time systems lab, computer science and engineering, asu cse 438/598 embedded systems...
TRANSCRIPT
Real-time Systems Lab, Computer Science and Engineering, ASU
CSE 438/598 Embedded Systems Programming – Fall 2014
Computer Science & Engineering DepartmentArizona State University
Tempe, AZ 85287
Dr. Yann-Hang [email protected](480) 727-7507
Real-time Systems Lab, Computer Science and Engineering, ASU
Course Syllabus (1)
Course Goals: Understand the design issues of embedded software and gain an
in-depth knowledge of development and execution environment. Understand the functions and the internal structure of device
interfaces, drivers, and real-time operating systems. Acquire the skill to develop multi-threaded embedded software in
target environment, including good quality and coding style for embedded programming, and testing and debugging approaches.
Develop feasible task scheduling and carry out system performance and task schedulability analyses.
Pre-requisites: Assembly language and computer organization (CSE230),
microprocessor interfaces (CSE 325), and experience of C programming language
Knowledge of operating systems and computer architecture
2
Real-time Systems Lab, Computer Science and Engineering, ASU
Course Syllabus (2)
Introduction: characteristics of embedded applications (2 lecture) Embedded processor architecture: processor architecture,
exceptions and interrupts, and system memory map. (4 lectures) Device interface and programming approaches: interconnection
architecture, serial buses, and device controllers (3 lectures) Device driver: software structure of device driver, Linux loadable
kernel module, blocking and non-blocking IO, top-half and bottom-half ISR. (6 lectures)
Embedded software and thread programming: task model and specification, periodic and aperiodic tasks, imprecise computation, overrun management, signaling, setjmp and longjmp. (5 lectures)
Basic RTOS and services for multiple threads or tasks, mutexes, semaphores and software timers. (4 lectures)
Scheduling algorithms and analysis: cyclic, rate-monotonic, and EDF,scheduling,, priority inheritance, and analysis. (4 lectures)
3
Real-time Systems Lab, Computer Science and Engineering, ASU
Course Syllabus (3)
Office hours –2:30pm-4:00pm, Tuesday and Thursday Evaluation
1st midterm exam* (20%) (in class, 75 minutes, Tuesday, Oct. 21) 2nd midterm exam* (30%) (12:10pm-2:00pm, Thursday, Dec. 11) 5 Lab assignments (40%) Class attendance and participation, discussion board participation,
and video sharing (10%) All exams are closed book and closed notes. The lab assignments must be done individually. There will be a
20% deduction per day for late submission. Request a regrade of exam or assignments within a week from the
date that the grade is returned. Plagiarism and other anti-intellectual behavior will be dealt with
severely.
4
Real-time Systems Lab, Computer Science and Engineering, ASU
Lab Setup
Intel Galileo board and additional periperals
Prepare your own micro SD card (and adapter) for booting
Preferred development software Linux, Eclipse, command lines, GUN tools
5
Real-time Systems Lab, Computer Science and Engineering, ASU
Real-time Embedded Systems
Embedded system the software and hardware component that is an
essential part of another system Real-time system
provide well-timed
computation deadlines, jitters,
periodicity temporal dependency
Plantsensor actuator
Control-rawcomputation
A/D
A/DD/AReference
input
Controller
6
Real-time Systems Lab, Computer Science and Engineering, ASU
Embedded Systems -- Examples
7
Real-time Systems Lab, Computer Science and Engineering, ASU
Emerging Embedded Systems
8
Real-time Systems Lab, Computer Science and Engineering, ASU
Embedded Systems
They are everywhere What are they?
Hardware (chips) + Software (programs)
for specific applications
CPU(micro-
processor)
I/O
I/O
I/O
I/O
Timer
memory
9
Real-time Systems Lab, Computer Science and Engineering, ASU
SW Development for RT ES
To write the control software for a smart washer initialize read keypad or control knob read sensors take an action
System current state state transition diagram external triggers via
polling or ISR If there are multiple triggers and
external conditions – single or multiple control loops
initialization
external trigger?
Take actions
Change system state
ISR: to set/clearevents
10
Real-time Systems Lab, Computer Science and Engineering, ASU
SW Development for RT ES
In the example of smart washer Never-ending in a single control loop Single execution threat and one address space Event triggering and state transitions Small memory footprint
What are missing: no concurrency (real-world events occur in parallel) no explicit timing control (let’s add a timer) difficult to develop and maintain large embedded systems –
verifiable, reusable, and maintainable
11
Real-time Systems Lab, Computer Science and Engineering, ASU
RT ES vs. General Software
Multi-tasking for concurrent events Machine dependence and portability Software abstraction, modular design
information hiding, OO, separate compilation, reusable a sorting procedure -- function, input, output specification
Control timing predictable actions in response to external stimuli deadline (absolute or relative), and jitter
Resource constraints and sharing CPU time, stack, memory, and bandwidth
Scheduling
12
Real-time Systems Lab, Computer Science and Engineering, ASU
Embedded System Development
Need a real-time (embedded) operating system (RTOS) or run on bare metal ?
Need a development and test environment ? Use the host to edit, compile, and build application programs At the target, use tools to load, execute, debug, and monitor
(performance and timing)
Development Host (gnu tool chain + Eclipse)
Target Peripherals + Plant Model
13
Real-time Systems Lab, Computer Science and Engineering, ASU
Development Environment of Linux
Host PC workstation
gcc cross-compiler
Linux
Eclipse IDEGDB Server
Target board
Board
support package
Applications
Linux or Windows
GDB debugger
Command line or IDE (Eclipse, Kdevelop)
Linux and GNU tools
14
Real-time Systems Lab, Computer Science and Engineering, ASU
HelloWorld Example
/* Hello World program */#include <stdio.h>#include <time.h>
int main(void) { int i; time_t curTime;
for (i=0; i<10; i++) { curTime = time(NULL);
printf("Hello, world. The current time is: %s", ctime (&curTime));sleep(i);
}}
CC = i586-poky-linux-gccall: HelloWorld.c
$(CC) -o HelloWorld.o HelloWorld.c
scp HelloWorld.o [email protected]:/home/root/labs/
15
Real-time Systems Lab, Computer Science and Engineering, ASU
Compiler, linker, and loader In ELF: executable, relocatable, shared library, and core
information for relocation, symbol, debugging linker resolves symbol reference
Link script or link command file assigns absolute memory addresses (program area, static data, bss,
stack, vector table, etc.) Startup code to disable interrupts, initialize stack, data, zero
uninitialized data area, and call main().
From Source to Executable
cc
asm
ldlinker loader debugger
linker script executable
16
Real-time Systems Lab, Computer Science and Engineering, ASU
Debugger
Observability, real-time analysis, and run control At host: GUI, source code, symbol table, type
information, line number Communication to the target
serial port, Ethernet, USB, etc. read/write memory and registers control processor execution (single step, breakpoint, watchpoint,
etc.) At target:
debugging stub (software): at breakpoint, replace the instruction with breakpoint inst. or invalid instruction to trigger exception
BDM (JTAG interface): hardware breakpoint, trace buffer, flash programming
17
Real-time Systems Lab, Computer Science and Engineering, ASU
Trends of RT Embedded Systems Applications
Wide-spreading, distributed, connected, and heterogeneous Mission and safety critical High-end consumer products
cell phone, HDTV, home network, PDA, GPS, appliances Quality of the products
portable/reusable, reliable/dependable, interoperable, predictable (schedulable), and secured
Software extensive A new S-class Mercedes-Benz
over 20 million lines of code nearly as many ECUs as the new Airbus A380 (excluding the plane's
in-flight entertainment system).
18
Real-time Systems Lab, Computer Science and Engineering, ASU
Software Complexity
Software in Smartphones = apps + android + Linux Linux kernel:
Android:
Language Code Comment Blank PercentageC 15,213,100 3,277,849 2,919,083 94.5%Assembly 474,013 99,107 77,428 2.9%C++ 238,689 107,606 49,138 1.7%XML 85,470 520 7,079 0.4%Make 39,575 11,901 10,859 0.3%Totals 16,086,836 3,504,100 3,070,580
Language Code Comment Blank PercentageC 4,790,691 1,541,950 1,021,643 42.5%C++ 2,922,477 896,141 624,506 25.7%Java 1,530,288 770,935 321,929 15.2%HTML 955,041 51,284 220,949 7.1%XML 524,855 75,396 34,453 3.7%Totals 11,431,145 3,546,030 2,333,226
(Analyses from http://www.ohloh.net/)
19
Real-time Systems Lab, Computer Science and Engineering, ASU
Reliable Embedded Software
Bill Gate: in FOCUS, 1995, “There are no significant bugs in our released
software that any significant number of users want fixed.” Numerous recalls for software bugs have occurred in
automobiles Smart cars: transition from mechanical to electronic control Toyota Prius: a software problem that caused the gas engines
to stall at highway speeds Volvo’s recall of S60 sedans due to software problems with the
fuel pumps. Jaguar: a software bug prevented cruise control from being
turned off
20
Real-time Systems Lab, Computer Science and Engineering, ASU
Toyota’s ETCS-i and Unintended Acceleration
Electronic Throttle Control System, Intelligent (ETCS-i) a closed loop throttle control function. learning algorithms to recalibrate sensor inputs. NASA “found no electronic flaws .. to create UA incidents”
But, in Appendix A compiler warnings extensive use of global
variables, indirection,
name overloading, and
code duplication dead code, warnings from
static analyzer violations of coding standards (NASA Engi. and Safety Center Technical
Assessment Report)
21
Real-time Systems Lab, Computer Science and Engineering, ASU
Advances in general-purpose computers PCs are powerful, cheap, and versatile Information processing is ubiquitous
Thanks for the growth in productivity The design gaps
Building Embedded Systems
Process technology
Hardware design
Software design
2x/18 months
1.6x/18 months
2x/5 years
0 3 6 9 12 151
10
100
1,000
HW gap
SW gap
(International Technology Roadmap for Semiconductors, 2011)
22
Real-time Systems Lab, Computer Science and Engineering, ASU
Embedded Software
Characteristics Concurrent, time dependent, and device/environment dependent
Embedded software development 80% programs in embedded system is with C/C++ and 15% in
assembly the same thing that has been done more than 30 years (Ada?)
Software complexities inherent and cannot be eliminated, i.e. algorithm, concurrency, etc. accidental (due to technology or methods used), i.e. memory leaks
What can we do? abstraction (e.g. high-level languages, modeling) automation (e.g. compiler)
23
Real-time Systems Lab, Computer Science and Engineering, ASU
Design for Performance and Predictability
A system vs. a piece of code Computer science is about abstraction, but resource is
needed to run any piece of code a switch statement a branch table if (unlikely(!timer)) return -EINVAL;
Benchmarking and profiling data measurement and interpretation resource usage and hot spots
A good understanding on what hardware and software are doing space and time tradeoff compiler optimization time and resource requirement
abstract
physical
model
data structure
algorithm
O(n), O(n2)…
object
operating system
compiler library
CPUmemory
instruction set
IO & Bus
time/cyclesignal
24
Real-time Systems Lab, Computer Science and Engineering, ASU
Embedded Coding Practices
Informal rules to improve the quality of software applications simplify their maintenance
MISRA-C:2012 143 rules checkable using static code analysis makes development as predictable as possible, across projects or
pieces of code, without errors of interpretation Holzmann’s “Power of Ten” and JPL coding standard Examples:
check return value of non-void functions name convention – dump_data_to_file() no compilation warnings no errors or warnings resulting from static code analyzers
(Image credit: Wikidave)
25
Real-time Systems Lab, Computer Science and Engineering, ASU
Embedded Software Analysis Tools (1)
Static and dynamic tools to show the correctness and performance of software systems
VDC Research (2012-02-01). "Automated Defect Prevention for Embedded Software Quality"
26
Real-time Systems Lab, Computer Science and Engineering, ASU
Embedded Software Analysis Tools (2)
A simple example:
Static analysis tools Lint, PolySpace, CODAN of Eclipse null pointer de-reference, use after free, array indexing errors,
stack and heap overrun, etc.
IDE, debug and trace tools Performance and profiling tools:
gprof, perf, Valgrind profiler,
Intel Amplifier Memory and thread tools:
Valgrinde memcheck and DRD, Intel Inspector
in single core in dual core
vs.
(Wind River Workbench’s System Viewer)
27