Understanding Embedded Systems: A Comprehensive Guide

I have always wanted to find time to write a popular science article about the concept of embedded systems. During the Spring Festival, Jiatang-kun was on vacation, and after returning, I immediately entered a high-intensity learning state. Today, I plan to write this article after class, and after searching on Google and Wikipedia, I found detailed explanations, so I won’t spend time writing it and will simply copy Wikipedia’s content as a popular science article for review.

Embedded Systems (Embedded System) is a type of computer system that is embedded within mechanical or electrical systems, having a specific function and real-time computing performance. Embedded systems are often used for efficient control of many common devices, and the embedded system usually includes a complete device comprising digital hardware and mechanical components, such as the anti-lock braking system in cars. In contrast, general-purpose computers like personal computers are designed to be flexible and can intelligently handle various computational situations to meet the diverse needs of end users.

Modern embedded systems are typically based on microcontrollers (such as central processing units with integrated memory and/or peripheral interfaces), but in more complex systems, general-purpose microprocessors (using external memory chips and peripheral interface circuits) are also common. General-purpose processors, processors designed for specific types of calculations, and processors customized for handheld applications may all be applied to embedded systems. Common dedicated processors include digital signal processors.

The key feature of embedded systems is that they handle specific tasks, allowing engineers to optimize them to reduce product size and cost while enhancing reliability and performance.

The physical forms of embedded systems include portable devices such as pedometers, electronic watches, and MP3 players; large fixed installations such as traffic lights and factory controllers; and large complex systems such as hybrid cars, magnetic resonance imaging devices, and avionics. Their complexity ranges from microcontrollers to large chassis or enclosures containing multiple components, peripherals, and networks.

Table of Contents

• 1Examples of Embedded Systems

• 2History

• 3Characteristics

• 3.7.1Internal Self-Check

• 3.2.1Embedded Motherboard

• 3.2.2ASIC and FPGA Solutions

• 3.1User Interface

• 3.2Processors of Embedded Systems

• 3.3Peripheral Devices

• 3.4Tools

• 3.5Debugging

• 3.6Operating Systems

• 3.7Booting

• 3.8Reliability Systems

• 4Types of Embedded Software Architecture

• 4.1Control Loop

• 4.2Non-Preemptive Tasks

• 4.3Preemptive Timers

• 4.4Preemptive Tasks

• 4.5Microkernel and Macrokernel

• 4.6Virtual Machines

• 4.7Checkpoint Computing

• 4.8Office Use (Macrokernel) Operating Systems

• 4.9Exotic Custom Operating Systems

• 5External Links

• 6Common Embedded Operating Systems

• 7Common Open Source Embedded Hardware and Software Systems in the Industry

• 8References

Examples of Embedded Systems

Embedded systems are commonly used in consumer, cooking, industrial, automation, medical, commercial, and military fields.

• Telecommunications Systems

A large number of embedded systems are deployed from network-level telephone switches to mobile terminals.

• Consumer Electronics

Includes PDA, MP3 players, mobile phones, game consoles, digital cameras, DVD players, global positioning system receivers, and printers.

• Home Applications

Embedded systems are used in microwaves, washing machines, and dishwashers, providing flexibility, efficiency, and functionality; advanced HVAC systems use networked thermostats for more precise and efficient daily or seasonal temperature control; smart homes use embedded devices for sensing and control, managing lighting, temperature and humidity, security, audio and video, monitoring, etc., through wired and wireless networks.

• Transportation Systems

Advanced avionics are used in aircraft where safety requirements are quite high, such as inertial navigation systems and global positioning receivers; various motors — brushless DC motors, asynchronous motors, and DC motors use electrical/electronic motor controllers; embedded systems are increasingly adopted in cars, electric vehicles, and hybrid vehicles for energy conservation and emission reduction; other automotive safety systems include anti-lock braking systems, electronic stability control systems, traction control systems, and automatic four-wheel drive systems.

• Medical Devices

Embedded devices are used for monitoring vital signs, electronic stethoscopes amplify sounds, and various medical imaging systems (such as positron emission tomography, single-photon emission computed tomography, computed tomography, magnetic resonance imaging) perform non-invasive internal inspections; embedded systems within medical devices typically use industrial computers.

Embedded systems are applied in transportation, fire safety, security, medical, and life-critical systems, as they can isolate from hackers, making them more reliable. In fire safety, systems are designed to operate continuously in high-temperature environments. For safety purposes, embedded systems can be self-sufficient, capable of handling situations where electrical and communication systems are cut off.

The development of the WSN field has led to the rapid proliferation of a new type of miniaturized wireless device called smart dust. People can perceive and act upon countless objects in the physical world through information monitoring and control systems. Smart dust uses micro-manufacturing technology, combining wireless subsystems with cutting-edge sensors; thus, people can perceive and act upon countless objects in the physical world through information monitoring and control systems. These smart dust devices are fully self-sufficient and can typically operate for years before needing battery replacement or recharging.

Using embedded Wi-Fi modules, devices that previously used serial ports for communication can easily enable wireless communication capabilities.

History

The Apollo Guidance Computer developed by Charles Stark Draper at MIT Instrumentation Laboratory is one of the prototypes of modern embedded systems. In the early stages of the project, it was considered the riskiest part because it used the latest single-chip integrated circuits developed at that time to reduce size and weight.

The first mass-produced embedded system was the D-17 automatic guidance computer inside the Minuteman I missile, released in 1961. When the Minuteman II missile began production in 1966, the D-17 was upgraded to a new type of computer that used integrated circuits extensively for the first time. This project alone reduced the unit price of the anti-lock brake module from $1000 to $3, low enough for commercial products.

Due to these early applications in the 1960s, not only did the price of embedded systems decrease, but their processing power and functionality also improved significantly. Taking the first microcontroller, the Intel 4004, as an example, it was designed for calculators and other small systems but still required external memory and peripheral chips. In 1978, the National Engineering Manufacturers Association released a “standard” for programmable microcontrollers, covering almost all computer-based controllers, such as single-board computers, CNC devices, and event-based controllers.

As the prices of microcontrollers and microprocessors decreased, consumer products could replace button-based analog devices, such as voltage dividers and variable capacitors, with microprocessors that read switch or button signals.

By the early 1980s, memory and input/output components were integrated into processors, resulting in microcontrollers. In applications where the cost of using general-purpose computers was too high, microcontrollers took their place.

Lower-cost microcontrollers can replace many standalone components after programming; these embedded systems are often more complex than traditional solutions, but most of this complexity is reflected in the microcontroller itself. Embedded systems require very few peripheral components, and most design work focuses on software, with the creation and testing of software prototypes occurring faster than designing and creating new circuits that do not use embedded processors.

Characteristics

Unlike general-purpose computers that can execute multiple tasks, embedded systems are designed for specific tasks. Some systems must meet real-time requirements to ensure safety and availability; others have very low or no performance requirements to simplify hardware and reduce costs.

Embedded systems are not always standalone devices. Many embedded systems consist of small computing components embedded within larger devices, providing more general functionality. For example, a guitar robot uses embedded systems to tune, but its design purpose is not primarily tuning but rather playing music; on-board computers exist as subsystems within cars, providing navigation, control, vehicle status feedback, and other functions.

The programs written for embedded systems are called firmware, stored in read-only memory or flash memory chips, running on limited hardware resources: small memory capacity, small keypads or screens, or sometimes no screens at all.

User Interface

The user interface of embedded systems ranges from no user interface, focusing solely on a single task, to complex graphical user interfaces similar to modern desktop operating systems.

Simple embedded devices use buttons, LEDs, graphical or numeric LCDs, and simple menu systems.

Higher-end embedded systems use graphical displays, combined with touch sensitivity or edge buttons, to minimize space and provide flexibility: the meaning of buttons changes according to the content displayed on the screen, and selecting desired options can be achieved by pointing to them.Handheld systems often use a display plus joystick buttons as touch control devices.

Some systems provide user interfaces remotely via serial communication interfaces (such as RS-232, USB, I2C, etc.) or network connections. The advantage of this approach is that it expands the system’s performance, reduces the cost of displays, simplifies the BSP, allowing for rich user interfaces to be built on a PC. For example, embedded web servers running on embedded device platforms (such as IP cameras or routers) display user interfaces in the network browser of a connected PC without requiring custom software installation.

Processors of Embedded Systems

Embedded processors can generally be divided into two categories. One category is general-purpose microprocessors: using separate integrated circuit memory and peripherals. The other category is microcontrollers: which have on-chip peripherals, reducing power consumption, size, and cost. The software for embedded systems is tailored for specific applications, rather than being commodity software installed by end users like personal computers, allowing the use of various basic CPU architectures: both von Neumann architecture and varying degrees of Harvard architecture; both RISC and non-reduced instruction set processors; word lengths ranging from 4 bits to 64 bits or even higher, with the most typical still being 8/16 bits. Most architectures are produced by several different companies, using a large number of different variables and types.

Embedded systems may also use general-purpose microprocessors, but they require more peripheral circuits than microcontrollers.

Embedded Motherboard

PC/104 and PC/104+ are standards for small, low-volume embedded rugged systems, mostly based on x86 architecture; they are usually smaller than standard PCs but larger than most simple 8/16-bit embedded systems; they use MSDOS, Linux, NetBSD, or real-time embedded operating systems such as MicroC/OS-II, QNX, and VxWorks. Sometimes these motherboards also use non-x86 processors.

In some applications, compactness and efficiency are not the main concerns, allowing the use of components compatible with x86-type PC motherboards. VIA EPIA series boards fill this gap, being compatible with PCs but highly integrated and smaller, or offering other features appealing to embedded engineers. The benefit of this approach is that low-cost commodities can use general software development tools. Systems built using this method are still embedded systems because they are embedded in larger devices for a single purpose. For example, ATMs and game consoles both contain code tailored to their respective applications.

Most embedded motherboards are not designed around PCs and do not use ISA or PCI buses. If SoC processors are used, connecting discrete components with standard buses is not advisable, and the hardware and software development environments may differ significantly.

A common design pattern is to use small system modules—perhaps only the size of a business card—housing high-density BGA chips like ARM processors and peripherals, external flash memory for storage, and DRAM as memory. Module vendors typically provide boot software and operating system options, generally including Linux and some real-time operating systems. These modules are mass-produced by organizations familiar with specialized testing methods, used with custom motherboards with special application peripherals in smaller quantities.

ASIC and FPGA Solutions

SoC is a common configurable array designed for ultra-large-scale embedded systems. It contains multiple processors, multipliers, caches, and interfaces within a single chip, forming a complete system; it is implemented via application-specific integrated circuits or field-programmable gate arrays.

Peripheral Devices

Embedded systems communicate with the outside world through peripherals:

• Serial communication interfaces:RS-232, RS-422, RS-485, etc.

• Synchronous serial communication interfaces:I2C, SPI, ESSI, etc.

• USB

• Multimedia cards:SD cards, CF cards, etc.

• Network:Ethernet, LonWorks, etc.

• Field buses:CAN bus, LIN bus, PROFIBUS, etc.

• Timers:PLL, capture compare modules, and time processing units

• Discrete I/O:GPIO

• Analog-to-digital/digital-to-analog conversion (ADC/DAC)

• Debugging interfaces:JTAG, ISP, ICSP, BDM ports, BITP, DP9 ports, etc.

Tools

Like typical computer programmers, embedded system designers also use compilers, linkers, and debuggers to develop embedded system software. However, they also use some tools that most programmers are unfamiliar with.

Sources of software tools include:

• Software companies focused on the embedded systems market

• Porting from GNU software development tools (see cross-platform compilation)

• In some cases, if the embedded processor is very similar to a regular personal computer processor, personal computer development tools can also be used

Embedded system designers also use some software tools that are not familiar to typical computer programmers:

• A commonly used tool is the “in-circuit emulator” (ICE) or the embedded debugger in the latest designs. This debugging tool is essential for developing embedded programs. It replaces the microprocessor or embeds it internally, providing a convenient tool for quickly calling and debugging experimental code in the system. A solder point is usually a special circuit inserted into the system, typically using a personal computer connected to these solder points as the debugging interface.

• Linkers can vary widely. For most commercial programming, linkers are almost an afterthought, with default settings rarely changed. In contrast, embedded linkers often have a complete and complex command-line language. There are often different types of memory, storing special code and data separately. Individual data structures can be placed at special addresses, making it easy for software to access control registers mapped to memory. Embedded linkers often have features for reducing code size and runtime. For example, they may move subroutine locations to use smaller call and jump instructions. They often come with features for managing data overlays and band switch techniques, which are methods used in embedded software to extend inexpensive CPU capabilities.

• Another commonly used tool is a program that adds code and/or CRC to the program (often written by the user), allowing the embedded systems to perform program data checks before executing the program.

• Embedded programmers developing software for digital signal processing often use mathematical tools like MathCad or Mathematica for mathematical simulation.

• Some lesser-used tools convert data files into code, allowing any type of data to be included in the program.

• A few projects require special reliability or digital signal processing features, using synchronous programming languages.

Some programming languages provide special support for embedded system programming.

• For C language, ISO/IEC TR 18037:2005 defines:

• Designated address space

• Designated storage classes

• Hardware addressing for basic input and output

Debugging

Debugging typically uses in-circuit emulators or other debuggers that can generate interrupts within the microcontroller’s microcode. Microcode interrupts allow the debugger to operate in hardware where only the CPU is working, and CPU-based debuggers can test and debug the computer’s circuits from the CPU’s perspective. PDP-11 pioneered this feature.

Developers can still use breakpoints, single-stepping, and high-level languages for debugging, and many debugging tools have this capability. Additionally, developers need to log events when debugging the order of real-time events.

Personal computer and mainframe programmers who first encountered such issues often find themselves confused when designing priorities and feasible methods. Guidance, code reviews, and non-personal styles (such as egoless programming) are recommended.

As embedded systems become increasingly complex, higher-level tools and operating systems are gradually being ported to feasible devices. For example, cellular phones, personal digital assistants, and other consumer computers require important software that may need to be purchased or provided by companies outside of personal or these electronic device manufacturers. In these systems, open programming environments such as Linux, OSGi, or Java are needed so that third-party software providers can sell software in the mass market.

Most of such development environments have a reference design running on a personal computer, and most of this software can be developed on traditional personal computers. However, porting from open environments to dedicated electronic devices and developing drivers for these devices is still often the work of traditional embedded systems software engineers. In some cases, the engineer works for the integrated circuit manufacturer, but there is still such a person somewhere.

Operating Systems

Embedded systems often have no operating system, a dedicated embedded operating system (often a real-time operating system), or a system that programmers port to these new systems.

Booting

Embedded systems come with boot code, which typically disables interrupts, sets device parameters, tests the computer (RAM, CPU, and software), and then starts running the application program. Many embedded systems recover from brief power outages, often restarting without performing the latest self-checks. Restarting within a tenth of a second is common.

Many designers find LEDs very useful for indicating error states, as they can assist in troubleshooting. A common mechanism is to light up all LEDs of the electronic device upon reset to indicate power and LED functionality; then, during power-on self-tests, the software changes the state of the LEDs; afterward, the software uses these LEDs to indicate normal or fault states during operation. This can inform technicians, engineers, and users of the system’s status. An interesting exception is electric power meters and other items on the street, where flashing indicators are meant to attract attention or indicate a fault state.

Internal Self-Check

Many embedded systems have some degree or number of internal power-on self-checks, which can take several forms:

1. Computer Checks: Check CPU, RAM, and program memory. These checks usually begin upon power-up; in some systems where safety is critical, self-checks are often performed periodically within safety time intervals or after a certain period.

2. Peripheral Checks: Simulate inputs and read data or measure output data. Many communication, analog, and control systems have these very inexpensive checks.

3. Power Checks: Typically test each power supply circuit and may also check battery or main power input. The load on the power supply part is often heavy, and there is little margin, so this check is meaningful.

4. Communication Checks: Verify simple messages received from connected units, such as using ICMP messages “ping” on the Internet.

5. Cable Checks: Connect wires to the pins of the cable to be checked. Synchronous communication systems, like telephones, often use “synchronous” testing. Cable checks are inexpensive, especially important when the unit has plugs.

6. Equipment Checks: A system often needs adjustments upon installation, and this check provides status indications to installers.

7. Consumption Checks: Check items consumed by the system, issuing warnings when pre-defined thresholds are too low. The most common example is the fuel gauge in cars, while the most complex example might be an automated medical analysis system maintaining detailed states of chemical reactants.

8. Operational Checks: Check the operational state of the system that users care about. Clearly, these checks must be performed while the system is running, including navigation instruments on aircraft, speedometers in cars, and indicator lights on disks.

9. Safety Checks: Conduct checks within ‘safety time limits’ to ensure the system remains reliable. Safety time limits are typically less than the minimum time that could cause harm.

Reliability Systems

Depending on people’s needs, reliability can have different definitions. Interestingly, the types of reliability are relatively few, and systems with similar reliability types use similar internal checks and recovery methods:

1. Systems that are very unsafe or unrepairable. This includes space systems, underwater cables, navigation lighthouses, drilling systems, and oddly enough, cars and mass-produced products. Generally, embedded systems check various subsystems, switch online to redundant parts, or operate in “limp mode” to provide partial functionality. Mass-produced consumer products like cars, personal computers, or printers also fall into this category, as repair costs are high compared to purchase costs, and repair personnel are often far away.

2. Systems that cannot safely stop running. This includes aircraft navigation, reaction control systems, critical chemical plant safety controls, railway signals, and the engines of single-engine aircraft, as mentioned above; however, “limp mode” is often hard to tolerate, usually requiring operators to choose backup systems.

3. Systems that will incur significant monetary losses if they stop running. These include telephone switches, factory controls, bridge and elevator controls, fund transfers, market development, automated sales and services, etc. These systems often have some operational/non-operational tests, typically with online redundancy or using replacement systems and manual processes in limp mode.

4. Systems that cannot operate when unsafe. This is similar to the above situation, where system operation would cause significant monetary losses. Medical devices, aircraft with engine hot backups, chemical plant controls, automated stock trading, gaming systems, etc. Testing can vary widely, but when errors occur, the only option is to stop the entire system.

Types of Embedded Software Architecture

Several basic types of embedded software architecture are commonly used.

Control Loop

In this design, the software has a simple loop that calls various subroutines, each managing a part of the hardware or software. Interrupts are typically used to set flags or update registers that other parts of the software can read.

The system uses simple APIs to allow and disallow interrupt settings. If handled properly, it can manage nested calls within nested subroutines, restoring the previous interrupt state at the outermost interrupt. This method is one of the simplest ways to implement Exokernel.

Typically, some subroutines in the loop use periodic immediate interrupts to control a set of software timers, executing the corresponding subroutine or setting appropriate flags when a timer expires.

Any possible hardware events should have software timer support; hardware events occur roughly once in a trillion times, for modern hardware, about once a year, and for millions of mass-produced devices, missing a software timer could be commercially disastrous.

Sometimes, software tests run a set of software-based safety timers, which periodically reset the watchdog software in the hardware. If the software misses an event, the safety timer software will capture it. If the safety timer fails, the watchdog hardware will reset the system.

State machines can be implemented using pointers to functions for each state, which can be implemented in C++, C, or assembly language. Changing states places different functions in the pointers, executing the function pointers during each loop run.

Many designers recommend reading input/output devices once per loop and saving the results to ensure logical processes run on consistent parameters.

Many designers prefer to design state machines to check only one or two items per state, usually checking hardware events and software timers.

Designers suggest that multi-level state machines should allow lower-level state machines to run before higher-level state machines so that the higher-level can operate based on correct information.

Complex functions like internal combustion control are often handled based on multidimensional tables; the code typically performs table lookups rather than complex calculations, and to reduce table size and cost, software can perform interpolation between entries.

On minimal microcontrollers, especially those with only a 128-bit stack like the 8051, control loops allow good linkers to use statically allocated data to overwrite local variables. In this mechanism, variables closer to the end of the subroutine call tree get higher memory addresses. When starting a new branch, its variables can be reallocated in the space abandoned by previous branches.

A major drawback of simple control loops is that they cannot guarantee the timing of responding to specific hardware events.

Careful design can easily ensure that interrupts are not disabled for long periods, allowing interrupt code to run with very precise timing.

Another major drawback of control loops is that adding new features can become complex. Algorithms that take a long time must be carefully decomposed so that only a small part runs in the main loop each time.

The advantage of this system is its simplicity, and with very little software, it runs quickly, making it nearly irrelevant that it is unpredictable.

Another advantage is that this system guarantees the quality of the running software, and poor operating results cannot be blamed on other operating systems.

Non-Preemptive Tasks

Non-preemptive task systems are very similar to the above systems, except that this loop is hidden within the API. We define a series of tasks, each receiving its subroutine stack; then, when a task is idle, it calls an idle subroutine (usually called “pause”, “wait”, “yield”, etc.).

Architectures with similar properties have an event queue, with a loop determining deletion times and calling subroutines based on a field in the queue list.

The advantages and disadvantages of this architecture are very similar to control loops, except that this method makes adding new software easier, requiring only simple new tasks or adding them to the queue interpreter.

Preemptive Timers

Using any of the above systems, but adding a timer system that runs subroutines based on timer interrupts, thus giving the system new capabilities, allowing timer subroutines to run at guaranteed times.

Additionally, code can first access its data structures at unexpected times. Timer subroutines must be treated like interrupt subroutines.

Preemptive Tasks

Using the above non-preemptive task system, running from a preemptive timer or other interrupts.

This system suddenly becomes very different. Any task’s code can potentially damage other tasks’ data—so they must be divided. Access to shared data must be controlled using some synchronization strategies, such as message queues, semaphores, or non-blocking synchronization mechanisms.

Frequently at this stage, development organizations will purchase a real-time operating system. If an organization lacks the talent to write an operating system or if the operating system is going to be on several products, this may be a wise choice. This typically adds six to eight weeks to the development plan, and forever after programmers can blame delays on it.

Microkernel and Macrokernel

This approach attempts to organize the system in a more configurable manner than a macrokernel while providing similar features.

Microkernels are a logical development of real-time operating systems; the typical organization is that the operating system kernel allocates memory and switches the CPU between different threads. User-mode processes implement major functions such as file systems and user interfaces.

Microkernels were first attempted in the 1950s, but due to the slow speed of switching tasks and exchanging data between tasks, microkernels were abandoned in favor of MULTICS and UNIX-style large kernels. Overall, microkernels are more successful when task switching and inter-task communication speeds are fast, and they fail when speeds are slow.

Macrokernels achieve high communication efficiency through ordinary subroutine calls, and both hardware and software in the system can be used and extended by programmers. Resource kernels (which may be part of a library) allocate CPU time, memory, and other resources. Features of large kernels like multitasking, networking, and file systems are provided through code libraries. Libraries can be dynamically linked, extended, or shared. Different applications can even use different libraries, but all resources come from the resource kernel.

Virtual Machines

Some avionics systems use several commercial computers. Going further, each computer simulates several copies of itself, with important programs running simultaneously on several computers and conducting voting control.

The advantage of the simulated environment is that even if one computer fails, different routines of software can migrate to the software partitions that are functioning normally, and the votes are not affected.

Typically, virtual software runs in user mode on the computer, capturing and simulating hardware access and instructions that do not run in user mode.

Checkpoint Computing

Another commonly used mechanism is for two computers to compute for a bit and then report their results at that point. If one computer’s computation is incorrect, it will be shut down.

Office Use (Macrokernel) Operating Systems

This type of system is often popular in embedded projects without system funding, but from the perspective of multiple authors of this article, this is often incorrect. Their reasoning is:

• The operating system is a specially packaged reusable code library. If this code is useful, designers will save time and money; otherwise, it is useless.

• The operating system for business systems does not interface with embedded hardware. For example, if you want to write a motor controller or telephone switch with Linux, most of the actual control operations are IOCTL calls, while normal read, write, and query interfaces are useless. Therefore, the operating system greatly hinders actual development.

• Most embedded systems do not handle office affairs, so most of the code in office operating systems is wasted. For example, the vast majority of embedded systems never use file systems or screens, so the file system and graphical user interface portions are wasted, and this unused code only affects the system’s reliability.

• Office operating systems protect hardware from user programs, which severely hinders embedded development work.

• The operating system must be ported to embedded systems, meaning that hardware drivers must be rewritten anyway, which is also the most challenging part of the operating system, so using such an operating system is almost ineffective.

• The truly useful, portable features of operating systems are small segments of code. For example, a basic TCP/IP interface is about 3000 lines of code, and another example is a simple file system of about the same size. If the design requires this code, it can be completed with less than 10% of the embedded system development cost without paying any licensing fees, simply by rewriting it. If enough generality exists in this code, often companies selling royalty-free C language implementation code can be found on the back cover of embedded systems magazines.

However, many task programmers do not agree with this, and embedded Linux is becoming increasingly popular, especially in powerful embedded systems like wireless routers and global positioning systems. Some reasons include:

• There are ready-made implementations of code ported to ordinary embedded chips.

• They allow the reuse of publicly available device drivers, web servers, firewalls, or other code.

• Development systems can start with many feature combinations and remove unnecessary features during release, thereby saving memory consumption.

• Many task programmers believe that running applications in user mode is more reliable and easier to debug, making the development process easier and the code easier to port.

• Many embedded systems do not have the strict real-time requirements of control systems, and for many applications, systems like embedded Linux provide sufficient response speed.

• Features requiring faster response speed rather than reliability are usually placed on hardware.

• Many real-time operating systems charge fees for each product, which can be significant for consumer products.

Exotic Custom Operating Systems

Some systems require safety, timeliness, reliability, or efficiency features that the above architectures cannot achieve. Building such systems involves some well-known techniques:

• Hire a real system programmer. Their cost is low but can save years of debugging and related income losses.

• RMA (rate monotonic analysis) can be used to assess whether a set of tasks can run on a specific hardware system. In its simplest form, designers ensure that the tasks completed fastest have the highest priority, and on average, the CPU has at least 30% idle time.

• Harmonious tasks can efficiently optimize the CPU. Essentially, designers ensure that each job starts working from a heartbeat timer. This is difficult to do on real-time operating systems because they usually switch tasks while waiting for input/output devices.

• Systems with just two priorities (usually running and interrupt disabled) cannot have high-priority tasks waiting for low-priority tasks to release semaphores or other resources, avoiding priority inversion issues.

• Systems with monitors cannot experience deadlocks. Monitors lock a section of code, disabling interrupts and other preemptive tasks. If this monitor is used only for a small segment of quickly executing code, the system may work normally. If it can be proven that the monitor API can run completely in all cases, such as only disabling interrupts, then deadlock situations will not occur.

This means that systems using two priorities and monitors are safe and reliable, as they do not have deadlock and priority inversion issues. If the monitor can execute to completion, then it will never hang. If harmonious tasks are used, they may also be quite efficient. However, RMA cannot describe these systems, and priorities should not be everywhere, including operating systems and hardware.

External Links

• How Real-Time Operating Systems Work (English)

• Embedded Systems Portal (English)

• Windows Embedded Developer Center (English)

• Embedded Systems and VLIW Processors (English)

• Embedded C++ Home (English)

• QNX Home (English)

• LynuxWorks Embedded Systems Home (English)

• Embedded Systems Discussion Groups, Books, Job Opportunities, and More (English)

• Embedded Software Design (English)

• List of Universities with Embedded Systems Development Communities (English)

• Embedded Systems Programming (English)

• EE Overview – Electrical Engineering and Embedded Systems Programming (English)

• DeviceTools – Tools and Chips for Embedded Developers (English)

• Embedian (English)

• Embedded Computing Industry Magazine (English)

• Embedded White Papers, Downloads, Companies, News, Articles (English)

• Embedded Systems Troubleshooting – An Overview of Issues from Baseboard Brewing, Manufacturing, to Logistics. (English)

• Working across Multiple Embedded Platforms (English)

Common Embedded Operating Systems

See Embedded Operating Systems

• Android

• Firefox OS

• iPhone OS

• uC/OS II

• FreeRTOS

• uCLinux

• VxWorks

• pSOS

• Nucleus

• PalmOS

• Windows CE

• Windows XP Embedded

• Windows Vista Embedded

• Embedded Linux

• eCos

• QNX

• Lynx

• Symbian

• Arm-Linux

• RT-Thread

Common Open Source Embedded Hardware and Software Systems in the Industry

No Operating System	Operating System + Weak GUI	Operating System + GUI Interface
8/16-bit Processors	Arduino Development Board (complete hardware and software, open-source, currently popular) Reference designs provided by various microcontroller companies (e.g., Atmel, etc.)	1. Arduino Development Board (complete hardware and software, open-source, currently popular) 2. Ethernut/nutos project (hardware and software pairing, open-source, focused on computer networking) 3. uCosII operating system (software, open-source but commercial version requires a license fee) FreeRTOS operating system (software, open-source version provided by commercial companies, also sells corresponding commercial versions) 4. Keil RTX51 Real-Time Kernel (open-source, requires a license with Keil software)
32-bit Processors	1. Ethernut/nutos project (hardware and software pairing, open-source, focused on computer networking) 2. eCos operating system (software, open-source, advantage is customizable RTOS) 3. uClinux operating system (software, open-source, has corresponding hardware board uCsimm project) 4. FreeRTOS operating system (software, open-source version provided by commercial companies, also sells corresponding commercial versions) 5. Keil RTX Real-Time Kernel (open-source, requires a license with Keil software) 6. RT-thread operating system (software, open-source, developed in China, has simple GUI) 7. Ubuntu Core is a more secure, lightweight, open-source operating system based on Ubuntu, tailored for smart IoT.	1. Android Operating System 2. Beagle Board Project (hardware and software pairing, open-source) 3. Raspberry Pi Project (hardware and software pairing, open-source)

References

1. Jump^ Michael Barr. Embedded Systems Glossary. Neutrino Technical Library. [2007-04-21].

2. Jump^ Heath, Steve. Embedded systems design. EDN series for design engineers 2. Newnes. 2003: 2. ISBN 978-0-7506-5546-0. An embedded system is a microprocessor based system that is built to control a function or a range of functions.

Transcribed from Wikipedia!