CE 278 L1.pdf

T4(c) CE 278: Embedded Systems Design 1 By: Dr Emmanuel Effah 2022 Lecture one  Course Outline Hardware – I/O, memory, busses, devices, control logic, interfacing hardware to software...

T4(c) CE 278: Embedded Systems Design 1 By: Dr Emmanuel Effah 2022 Lecture one  Course Outline Hardware – I/O, memory, busses, devices, control logic, interfacing hardware to software Software – Lots of C and Python, device drivers, Software/Hardware interactions – Where is the best place to put functionality hardware or software? – What are the costs: performance, memory requirements (RAM and/or FLASH ROM), power, etc Communication Requirements Integration of hardware and software courses Programming, logic design, architecture, etc Algorithms, mathematics and common sense NB: We will be using RPi 3B+ Introduction to Computing by Emmanuel Effah 2  Course Objectives High-Level Goals 1. Understand the scientific principles and concepts behind embedded systems, 2. Obtain hands-on experience in programming embedded systems. 3. Understand the basics of embedded system application concepts such as signal processing and feedback control Understand, and be able to discuss and communicate intelligently about – embedded processor architecture and programming – I/O and device driver interfaces to embedded processors with networks, multimedia cards and disk drives – OS for concurrency, timeouts, scheduling, communication and synchronization Introduction to Computing by Emmanuel Effah 3  Where Could You End Up? Automotive systems – perhaps designing and developing “drive-by-wire” systems -- self-driving vehicles Telecommunications Consumer electronics cellular phones, MP3 devices, integrated cellular/tablet/kitchen sink Set-top boxes and HDTV Home appliances Internet appliances Defense and weapon systems Process control – gasoline processing, chemical refinement, Mining, brewery, etc Automated manufacturing – Supervisory Control and Data Acquisition (SCADA) Space applications – Satellite communications Introduction to Computing by Emmanuel Effah 4 Course Presentation Lectures Practical Project Activities will be supported with handouts and computers. Introduction to Computing by Emmanuel Effah 5 Course Assessment Attendance 10% Continuous Assessment 30% End of Semester 60% Pass mark 50% ❖ Requirement of results to be submitted ❖ A > 23% ❖ F < 8% Grading 80-100% A 70-79.9% B 60-69.9% C 50-59.9% D 0-49.9% FAIL Introduction to Computing by Emmanuel Effah 6 What’s an Embedded System? An embedded system (ES) is a combination of computer hardware and software, and perhaps additional mechanical or other parts, designed to perform a specific function. A good example is the microwave oven. Frequently, an embedded system is a component within some larger system. For example, modern cars and trucks contain many embedded systems. If an embedded system is designed well, the existence of the processor and software could be completely unnoticed by a user of the device. Such is the case for a microwave oven, VCR, or alarm clock. NB: general-purpose computer is not an ES because it’s not designed to perform a specific function. What’s an Embedded System? Embedded system: any device that includes a computer but is not itself a general-purpose computer. Application specific The design is specialized and optimized for specific application Don’t need all the general-purpose bells and whistles. Cellphone, Personal Digital Assistant (PDA), Printer, GPS, Automobile (engine, brakes, dash, etc.), Digital camera, iPod, Household appliances (microwave, air conditioning), Wrist watch and a lot more … Fact: > 95% of all microprocessors are used for embedded systems. Anti-Lock Brake System (ABS) Pumps brakes to reduce skidding. Real-time and safety Automotive Systems A high-end car may have 100 microprocessors: 4-bit microcontroller checks seat belt; microcontrollers run dashboard devices; 16/32-bit microprocessor controls engine; Navigation; Entertainment: DVD, audio, satellite radio… Future Cars may drive by themselves? Control your car by speaking out, or even your mind Why are those systems special? Application specific Specialize and optimize the design for specific application Not a general-purpose computer. Don’t need all the bells and whistles, e.g., hard drive, monitor, keyboard… Have to worry about both hardware and software Have to worry about non-functional constraints such as: Real-time, Memory footprint, Power, Reliability and safety and Cost Just functionally working is NOT enough! Examples Cyber-Physical Systems Smart Building Examples Smart Cities and Communities Intelligent Transportation System Public safety: Gunshot detection City surveillance and planning Traffic monitoring and control Air quality and noise monitoring Other Examples Semester Project Goal What are Real-Time Systems? One subclass of embedded systems is worthy of an introduction at this point. A real-time system is a computer system that has timing constraints and is partly specified in terms of its ability to make certain calculations or decisions in a timely manner. These necessary calculations are said to have deadlines for completion. And, for all practical purposes, a missed deadline is just as bad as a wrong answer. Design Requirements of ES Production cost Processing power Memory Development cost Number of units Expected lifetime Reliability Design Requirements of ES Common design methodology and concepts Embedded system basics Primary technologies of different system components Design considerations: real-time, power, cost Design Requirements of ES Practical hands-on skills also requires knowledge about the global digital agenda. Characteristics of an Embedded System The important characteristics of an embedded system are Speed (bytes/sec) : Should be high speed Power (watts) : Low power dissipation Size and weight : As far as possible small in size and low weight Accuracy (% error) : Must be very accurate Adaptability: High adaptability and accessibility. Reliability: Must be reliable over a long period of time. Purpose of Embedded System Data Collection/Storage/Representation Data Communication Data (Signal) Processing Monitoring Control Classification of Embedded System Based on Generation First Generation: The early embedded systems built around 8-bit microprocessors like 8085 and Z80 and 4- bit microcontrollers EX. stepper motor control units, Digital Telephone Keypads etc. Second Generation: Embedded Systems built around 16-bit microprocessors and 8 or 16-bit microcontrollers, following the first-generation embedded systems EX. SCADA, Data Acquisition Systems etc. Third Generation: Embedded Systems built around high performance 16/32 bit Microprocessors/controllers, Application Specific Instruction set processors like Digital Signal Processors (DSPs), and Application Specific Integrated Circuits (ASICs).The instruction set is complex and powerful. EX. Robotics, industrial process control, networking etc. Fourth Generation: Embedded Systems built around System on Chips (SoC’s), Re-configurable processors and multicore processors. It brings high performance, tight integration and miniaturization into the embedded device market EX Smart phone devices, MIDs etc. Classification of Embedded System Based on complexity & performance Requirements Small Scale: The embedded systems built around low performance and low cost 8- or 16-bit microprocessors/ microcontrollers. It is suitable for simple applications and where performance is not time critical. It may or may not contain OS. Medium Scale: Embedded Systems built around medium performance, low cost 16- or 32-bit microprocessors / microcontrollers or DSPs. These are slightly complex in hardware and firmware. It may contain GPOS/RTOS. Large Scale/Complex: Embedded Systems built around high performance 32- or 64-bit RISC processors/controllers, RSoC or multi-core processors and PLD. It requires complex hardware and software. This system may contain multiple processors/controllers and co-units/hardware accelerators for offloading the processing requirements from the main processor. It contains RTOS for scheduling, prioritization and management. Classification of Embedded System Based on deterministic behaviour It is applicable for Real Time systems. The application/task execution behavior for an embedded system can be either deterministic or non-deterministic 1. Soft Real time Systems: Missing a deadline may not be critical and can be tolerated to a certain degree 2. Hard Real time systems: Missing a program/task execution time deadline can have catastrophic consequences (financial, human loss of life, etc.) Based on Triggering 1. Event Triggered: Activities within the system (e.g., task run-times) are dynamic and depend upon occurrence of different events. 2. Time triggered: Activities within the system follow a statically computed schedule (i.e., they are allocated time slots during which they can take place) and thus by nature are predictable. Comparison of ES and General-Purpose Computers INTRODUCTION TO EMBEDDED SYSTEMS GENERAL-PURPOSE COMPUTERS Able to run a variety of software. Contain relatively high- performance hardware components (fast processors, data & program storage). Require an operating system (OS). Image Courtesy of Recording Connection of Canada 1.1 WHAT IS AN EMBEDDED SYSTEM? CH. 1: INTRODUCTION TO EMBEDDED SYSTEMS GENERAL-PURPOSE COMPUTERS Designed for heavy user Several implement data interaction. memory and program storage. Uses a variety of peripherals (displays, keyboards, mice, Possesses a distributed internet connections, wireless architecture (full functionality of communication capability). the computer is spread across multiple IC chips). Expensive ($100s - $1000s). Use a group of integrated circuits or chips (ICs). One implements the central processing unit Image Courtesy of (CPU). Recording Connection of Canada 1.1 WHAT IS AN EMBEDDED SYSTEM? CH. 1: INTRODUCTION TO EMBEDDED SYSTEMS EMBEDDED COMPUTERS Resources can be implemented on a single IC. Include a variety of peripherals (timers, analog-to-digital converters, digital-to- analog converters, serial interfaces). Small size makes them Image Courtesy of very versatile. Recording Connection of Canada 1.1 WHAT IS AN EMBEDDED SYSTEM? CH. 1: INTRODUCTION TO EMBEDDED SYSTEMS EMBEDDED COMPUTERS Contains firmware (only the needed software which is not intended to be changed frequently). May contain Real Time Operating Systems (RTOS) which are used as a task scheduler. Low cost (10s of cents to a few dollars). Image Courtesy of Recording Connection of Canada 1.1 WHAT IS AN EMBEDDED SYSTEM? CH. 1: INTRODUCTION TO EMBEDDED SYSTEMS EMBEDDED COMPUTERS Image Courtesy of Recording Connection of Canada 1.1 WHAT IS AN EMBEDDED SYSTEM?  EMBEDDED SYSTEM DESIGN PROCESS Aims: Review the Design Steps and methodology Importance of Knowledge of methodology 1. First, it allows us to keep a scorecard on a design to ensure that we have done everything we need to do, such as optimizing performance or performing functional tests. 2. Second, it allows us to develop computer-aided design tools for automating the entire process. 3. Third, a design methodology makes it much easier for members of a design team to communicate.  EMBEDDED SYSTEM DESIGN PROCESS Steps: top–down view Requirements Clearly, before we design a system, we must know what we are designing. The initial stages of the design process capture this information for use in creating the architecture and components. We generally proceed in two phases: First, we gather an informal description from the customers known as requirements, and we refine the requirements into a specification that contains enough information to begin designing the system architecture. Requirements may be functional (what the system does, normally, from Input to Output) or non-functional. We must of course capture the basic functions of the embedded system, but functional description is often not sufficient. Typical non-functional requirements include: Performance, Cost, Physical size and weight, Power consumption, Name, Purpose, Inputs and outputs, etc. Example: GPS MODULE: REQUIREMENTS FORM OF GPS MOVING MAP MODULE: Name: GPS moving map Purpose: Consumer-grade moving map for driving use Inputs: Power button, two control buttons Outputs: Back-lit LCD display 400 _ 600 Functions: Uses 5-receiver GPS system; three user-selectable resolutions; always displays current latitude and longitude Performance: Updates screen within 0.25 seconds upon movement Manufacturing cost: $30 Power: 100mW Physical size and weight: No more than 2” _ 6,” 12 ounces Example: GPS MODULE: Specification The specification is more precise—it serves as the contract between the customer and the architects. As such, the specification must be carefully written so that it accurately reflects the customer’s requirements and does so in a way that can be clearly followed during design. The specification should be understandable enough so that someone can verify that it meets system requirements and overall expectations of the customer. A specification of the GPS system would include several components: Data received from the GPS satellite constellation. Map data. User interface. Operations that must be performed to satisfy customer requests. Background actions required to keep the system running, such as operating the GPS receiver. Example: GPS MODULE: Architecture Design The specification does not say how the system does things, only what the system does. Describing how the system implements those functions is the purpose of the architecture. The architecture is a plan for the overall structure of the system that will be used later to design the components that make up the architecture. The creation of the architecture is the first phase of what many designers think of as design. This block diagram is still quite abstract—we have not yet specified which operations will be performed by software running on a CPU, what will be done by special-purpose hardware, and so on. The diagram does, however, go a long way toward describing how to implement the functions described in the specification. We clearly see, for example, that we need to search the topographic database and to render (i.e., draw) the results for the display. We have chosen to separate those functions so that we can potentially do them in parallel— performing rendering separately from searching the database may help us update the screen more fluidly. Example: GPS MODULE: Architecture Design BLOCK DIAGRAM FOR THE MOVING MAP Example: GPS MODULE: Architecture Design The hardware block diagram clearly shows that we have one central CPU surrounded by memory and I/O devices. In particular, we have chosen to use two memories: a frame buffer for the pixels to be displayed and a separate program/data memory for general use by the CPU. The software block diagram fairly closely follows the system block diagram, but we have added a timer to control when we read the buttons on the user interface and render data onto the screen. To have a truly complete architectural description, we require more detail, such as where units in the software block diagram will be executed in the hardware block diagram and when operations will be performed in time. Example: GPS MODULE: Architecture Design The architectural description tells us what components we need. The component design effort builds those components in conformance to the architecture and specification. The components will in general include both hardware—FPGAs, boards, and so on—and software modules. Some of the components will be ready-made. The CPU, for example, will be a standard component in almost all cases, as will memory chips and many other components. In the moving map, the GPS receiver is a good example of a specialized component that will nonetheless be a predesigned, standard component. We can also make use of standard software modules. Example: GPS MODULE: System Integration: Only after the components are built do we have the satisfaction of putting them together and seeing a working system. Of course, this phase usually consists of a lot more than just plugging everything together and standing back. Bugs are typically found during system integration, and good planning can help us find the bugs quickly. By building up the system in phases and running properly chosen tests, we can often find bugs more easily. If we debug only a few modules at a time, we are more likely to uncover the simple bugs and able to easily recognize them. Only by fixing the simple bugs early will we be able to uncover the more complex or obscure bugs that can be identified only by giving the system a hard workout Characteristics of Embedded systems Embedded systems possess certain specific characteristics and these are unique to each Embedded system. 1. Application and domain specific 2. Reactive and Real Time 3. Operates in harsh environments 4. Distributed 5. Small Size and weight 6. Power concerns 7. Single-functioned 8. Complex functionality 9. Tightly-constrained 10.Safety-critical Quality Attributes of Embedded System: Quality attributes are the non-functional requirements that need to be documented properly in any system design. Quality attributes can be classified as I. Operational quality attributes II. Non-operational quality attributes. I. Operational Quality Attributes: The operational quality attributes represent the relevant quality attributes related to the embedded system when it is in the operational mode or online mode. Characteristics of Embedded systems: Operational Quality Attributes are: 1. Response:- It is the measure of quickness of the system. It tells how fast the system is tracking the changes in input variables. Most of the E.S demands fast response which should be almost real time. Ex – Flight control application. Characteristics of Embedded systems: Operational Quality Attributes are: 2. Throughput: - It deals with the efficiency of a system. It can be defined as the rate of production or operation of a defined process over a stated period of time. The rates can be expressed in terms of products, batches produced or any other meaningful measurements. Ex – In case of card reader throughput means how many transactions the reader can perform in a minute or in an hour or in a day. Throughput is generally measured in terms of “Benchmark”. A Benchmark is a reference point by which something can be measured Characteristics of Embedded systems: Operational Quality Attributes are: 3. Reliability: - It is a measure of how much we can rely upon the proper functioning of the system. Mean Time Between Failure (MTBF) and Mean Time To Repair (MTTR) are the terms used in determining system reliability. MTBF gives the frequency of failures in hours/weeks/months. MTTR specifies how long the system is allowed to be out of order following a failure. For embedded system with critical application need, it should be of the order of minutes. 4. Maintainability: - It deals with support and maintenance to the end user or client in case of technical issues and product failure or on the basis of a routine system checkup. Reliability and maintainability are complementary to each other. A more reliable system means a system with less corrective maintainability requirements and vice versa. Maintainability can be broadly classified into two categories 1. Scheduled or Periodic maintenance (Preventive maintenance) 2. Corrective maintenance to unexpected failures Characteristics of Embedded systems: Operational Quality Attributes are: 5. Security: - Confidentiality, Integrity and availability are the three major measures of information security. Confidentiality deals with protection of data and application from unauthorized disclosure. Integrity deals with the protection of data and application from unauthorized modification. Availability deals with protection of data and application from unauthorized users. 6. Safety: - Safety deals with the possible damages that can happen to the operator, public and the environment due to the breakdown of an Embedded System. The breakdown of an embedded system may occur due to a hardware failure or a firmware failure. Safety analysis is a must in product engineering to evaluate the anticipated damages and determine the best course of action to bring down the consequences of damage to an acceptable level. Characteristics of Embedded systems: II. Non-Operational Quality Attributes: The quality attributes that needs to be addressed for the product not on the basis of operational aspects are grouped under this category. 1. Testability and Debug-ability: - Testability deals with how easily one can test the design, application and by which means it can be done. For an E.S testability is applicable to both the embedded hardware and firmware. Embedded hardware testing ensures that the peripherals and total hardware functions in the desired manner, whereas firmware testing ensures that the firmware is functioning in the expected way. Debug-ability is a means of debugging the product from unexpected behavior in the system Debug-ability is two level process 1. Hardware level 2.software level 1. Hardware level: It is used for finding the issues created by hardware problems. 2. Software level: It is employed for finding the errors created by the flaws in the software. Characteristics of Embedded systems: II. Non-Operational Quality Attributes 2. Evolvability: - It is a term which is closely related to Biology. It is referred as the non-heritable variation. For an embedded system evolvability refers to the ease with which the embedded product can be modified to take advantage of new firmware or hardware technologies. 3. Portability: - It is the measure of system independence. An embedded product is said to be portable if the product is capable of functioning in various environments, target processors and embedded operating systems. „Porting‟ represents the migration of embedded firmware written for one target processor to a different target processor. Characteristics of Embedded systems: II. Non-Operational Quality Attributes 4. Time-to-Prototype and Market: - It is the time elapsed between the conceptualization of a product and the time at which the product is ready for selling. The commercial embedded product market is highly competitive and time to market the product is critical factor in the success of commercial embedded product. There may be multiple players in embedded industry who develop products of the same category (like mobile phone). 5. Per Unit Cost and Revenue: - Cost is a factor which is closely monitored by both end user and product manufacturer. Cost is highly sensitive factor for commercial products Any failure to position the cost of a commercial product at a nominal rate may lead to the failure of the product in the market. Proper market study and cost benefit analysis should be carried out before taking a decision on the per- unit cost of the embedded product. The ultimate aim of the product is to generate marginal profit so the budget and total cost should be properly balanced to provide a marginal profit.