Presentation is loading. Please wait.

Presentation is loading. Please wait.

Real-time Systems Lab, Computer Science and Engineering, ASU CSE 438/598 Embedded Systems Programming – Fall 2014 Computer Science & Engineering Department.

Similar presentations


Presentation on theme: "Real-time Systems Lab, Computer Science and Engineering, ASU CSE 438/598 Embedded Systems Programming – Fall 2014 Computer Science & Engineering Department."— Presentation transcript:

1 Real-time Systems Lab, Computer Science and Engineering, ASU CSE 438/598 Embedded Systems Programming – Fall 2014 Computer Science & Engineering Department Arizona State University Tempe, AZ Dr. Yann-Hang Lee (480)

2 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 1

3 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) 2

4 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. 3

5 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 4

6 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 Plantsensoractuator Control-raw computation A/D D/A Reference input Controller 5

7 Real-time Systems Lab, Computer Science and Engineering, ASU Embedded Systems -- Examples 6

8 Real-time Systems Lab, Computer Science and Engineering, ASU Emerging Embedded Systems 7

9 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 Timer memory 8

10 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/clear events 9

11 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 10

12 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 11

13 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) TargetPeripherals + Plant Model 12

14 Real-time Systems Lab, Computer Science and Engineering, ASU Development Environment of Linux Host PC workstation gcc cross- compiler Linux Eclipse IDE GDB Server Target board Board support package Applications Linux or Windows GDB debugger Command line or IDE (Eclipse, Kdevelop) Linux and GNU tools 13

15 Real-time Systems Lab, Computer Science and Engineering, ASU HelloWorld Example /* Hello World program */ #include 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-gcc all: HelloWorld.c $(CC) -o HelloWorld.o HelloWorld.c scp HelloWorld.o 14

16 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 ld linker loader debugger linker script executable 15

17 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 16

18 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). 17

19 Real-time Systems Lab, Computer Science and Engineering, ASU Software Complexity  Software in Smartphones = apps + android + Linux  Linux kernel:  Android: LanguageCodeCommentBlankPercentage C15,213,1003,277,8492,919, % Assembly474,01399,10777,4282.9% C++238,689107,60649,1381.7% XML85, ,0790.4% Make39,57511,90110,8590.3% Totals16,086,8363,504,1003,070,580 LanguageCodeCommentBlankPercentage C4,790,6911,541,9501,021, % C++2,922,477896,141624, % Java1,530,288770,935321, % HTML955,04151,284220,9497.1% XML524,85575,39634,4533.7% Totals11,431,1453,546,0302,333,226 (Analyses from 18

20 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 19

21 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) 20

22 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 HW gap SW gap (International Technology Roadmap for Semiconductors, 2011) 21

23 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) 22

24 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(n 2 )… object operating system compiler library CPU memory instruction set IO & Bus time/cycle signal 23

25 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) 24

26 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 ( ). "Automated Defect Prevention for Embedded Software Quality" 25

27 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) 26


Download ppt "Real-time Systems Lab, Computer Science and Engineering, ASU CSE 438/598 Embedded Systems Programming – Fall 2014 Computer Science & Engineering Department."

Similar presentations


Ads by Google