Such systems can range in size from a few modular panel-mounted
controllers to large interconnected and interactive distributed control
systems with many thousands of field connections. Systems receive data
received from remote sensors measuring process variables (PVs), compare the collected data with desired setpoints (SPs), and derive command functions which are used to control a process through the final control elements (FCEs), such as control valves.
Larger systems are usually implemented by supervisory control and data acquisition (SCADA) systems, or distributed control systems (DCS), and programmable logic controllers (PLCs), though SCADA and PLC systems are scalable down to small systems with few control loops.
Such systems are extensively used in industries such as chemical
processing, pulp and paper manufacture, power generation, oil and gas
processing, and telecommunications.
Discrete controllers
Panel
mounted controllers with integral displays. The process value (PV), and
setvalue (SV) or setpoint are on the same scale for easy comparison.
The controller output is shown as MV (manipulated variable) with range
0-100%.
A
control loop using a discrete controller. Field signals are flow rate
measurement from the sensor, and control output to the valve. A valve
positioner ensures correct valve operation.
The simplest control systems are based around small discrete controllers with a single control loop
each. These are usually panel mounted which allows direct viewing of
the front panel and provides means of manual intervention by the
operator, either to manually control the process or to change control
setpoints. Originally these would be pneumatic controllers, a few of
which are still in use, but nearly all are now electronic.
Quite complex systems can be created with networks of these
controllers communicating using industry standard protocols. Networking
allow the use of local or remote SCADA operator interfaces, and enables
the cascading and interlocking of controllers. However, as the number of
control loops increase for a system design there is a point where the
use of a programmable logic controller (PLC) or distributed control system (DCS) is more manageable or cost-effective.
Distributed control systems
Functional
manufacturing control levels. DCS (including PLCs or RTUs) operate on
level 1. Level 2 contains the SCADA software and computing platform.
A distributed control system (DCS) is a digital processor control
system for a process or plant, wherein controller functions and field
connection modules are distributed throughout the system. As the number
of control loops grows, DCS becomes more cost effective than discrete
controllers. Additionally a DCS provides supervisory viewing and
management over large industrial processes. In a DCS, a hierarchy of
controllers is connected by communication networks, allowing centralised control rooms and local on-plant monitoring and control.
A DCS enables easy configuration of plant controls such as cascaded loops and interlocks, and easy interfacing with other computer systems such as production control.
It also enables more sophisticated alarm handling, introduces automatic
event logging, removes the need for physical records such as chart
recorders and allows the control equipment to be networked and thereby
located locally to equipment being controlled to reduce cabling.
A DCS typically uses custom-designed processors as controllers,
and uses either proprietary interconnections or standard protocols for
communication. Input and output modules form the peripheral components
of the system.
The processors receive information from input modules, process
the information and decide control actions to be performed by the output
modules. The input modules receive information from sensing instruments
in the process (or field) and the output modules transmit instructions
to the final control elements, such as control valves.
The field inputs and outputs can either be continuously changing analog signals e.g. current loop or 2 state signals that switch either on or off, such as relay contacts or a semiconductor switch.
Distributed control systems can normally also support Foundation Fieldbus, PROFIBUS, HART, Modbus
and other digital communication buses that carry not only input and
output signals but also advanced messages such as error diagnostics and
status signals.
SCADA systems
Supervisory control and data acquisition (SCADA) is a control system architecture that uses computers, networked data communications and graphical user interfaces
for high-level process supervisory management. The operator interfaces
which enable monitoring and the issuing of process commands, such as
controller set point changes, are handled through the SCADA supervisory
computer system. However, the real-time control logic or controller
calculations are performed by networked modules which connect to other
peripheral devices such as programmable logic controllers and discrete PID controllers which interface to the process plant or machinery.
The SCADA concept was developed as a universal means of remote
access to a variety of local control modules, which could be from
different manufacturers allowing access through standard automation protocols. In practice, large SCADA systems have grown to become very similar to distributed control systems
in function, but using multiple means of interfacing with the plant.
They can control large-scale processes that can include multiple sites,
and work over large distances.
This is a commonly-used architecture industrial control systems,
however there are concerns about SCADA systems being vulnerable to cyberwarfare or cyberterrorism attacks.
The SCADA software operates on a supervisory level as control actions are performed automatically by RTUs
or PLCs. SCADA control functions are usually restricted to basic
overriding or supervisory level intervention. A feedback control loop is
directly controlled by the RTU or PLC, but the SCADA software monitors
the overall performance of the loop. For example, a PLC may control the
flow of cooling water through part of an industrial process to a set
point level, but the SCADA system software will allow operators to
change the set points for the flow. The SCADA also enables alarm
conditions, such as loss of flow or high temperature, to be displayed
and recorded.
Programmable logic controllers
Siemens
Simatic S7-400 system in a rack, left-to-right: power supply unit
(PSU), CPU, interface module (IM) and communication processor (CP).
PLCs can range from small modular devices with tens of inputs and
outputs (I/O) in a housing integral with the processor, to large
rack-mounted modular devices with a count of thousands of I/O, and which
are often networked to other PLC and SCADA systems. They can be
designed for multiple arrangements of digital and analog inputs and
outputs, extended temperature ranges, immunity to electrical noise, and resistance to vibration and impact. Programs to control machine operation are typically stored in battery-backed-up or non-volatile memory.
History
A
pre-DCS era central control room. Whilst the controls are centralised
in one place, they are still discrete and not integrated into one
system.
A
DCS control room where plant information and controls are displayed on
computer graphics screens. The operators are seated as they can view and
control any part of the process from their screens, whilst retaining a
plant overview.
Process control
of large industrial plants has evolved through many stages. Initially,
control was from panels local to the process plant. However this
required personnel to attend to these dispersed panels, and there was no
overall view of the process. The next logical development was the
transmission of all plant measurements to a permanently-manned central
control room. Often the controllers were behind the control room panels,
and all automatic and manual control outputs were individually
transmitted back to plant in the form of pneumatic or electrical
signals. Effectively this was the centralisation of all the localised
panels, with the advantages of reduced manpower requirements and
consolidated overview of the process.
However, whilst providing a central control focus, this
arrangement was inflexible as each control loop had its own controller
hardware so system changes required reconfiguration of signals by
re-piping or re-wiring. It also required continual operator movement
within a large control room in order to monitor the whole process. With
the coming of electronic processors, high speed electronic signalling
networks and electronic graphic displays it became possible to replace
these discrete controllers with computer-based algorithms, hosted on a
network of input/output racks with their own control processors. These
could be distributed around the plant and would communicate with the
graphic displays in the control room. The concept of distributed control was realised.
The introduction of distributed control allowed flexible
interconnection and re-configuration of plant controls such as cascaded
loops and interlocks, and interfacing with other production computer
systems. It enabled sophisticated alarm handling, introduced automatic
event logging, removed the need for physical records such as chart
recorders, allowed the control racks to be networked and thereby located
locally to plant to reduce cabling runs, and provided high-level
overviews of plant status and production levels. For large control
systems, the general commercial name distributed control system
(DCS) was coined to refer to proprietary modular systems from many
manufacturers which integrated high speed networking and a full suite of
displays and control racks.
While the DCS was tailored to meet the needs of large continuous
industrial processes, in industries where combinatorial and sequential
logic was the primary requirement, the PLC evolved out of a need to
replace racks of relays and timers used for event-driven control. The
old controls were difficult to re-configure and debug, and PLC control
enabled networking of signals to a central control area with electronic
displays. PLC were first developed for the automotive industry on
vehicle production lines, where sequential logic was becoming very
complex.
It was soon adopted in a large number of other event-driven
applications as varied as printing presses and water treatment plants.
SCADA's history is rooted in distribution applications, such as
power, natural gas, and water pipelines, where there is a need to gather
remote data through potentially unreliable or intermittent
low-bandwidth and high-latency links. SCADA systems use open-loop control with sites that are widely separated geographically. A SCADA system uses remote terminal units
(RTUs) to send supervisory data back to a control center. Most RTU
systems always had some capacity to handle local control while the
master station is not available. However, over the years RTU systems
have grown more and more capable of handling local control.
The boundaries between DCS and SCADA/PLC systems are blurring as time goes on.
The technical limits that drove the designs of these various systems
are no longer as much of an issue. Many PLC platforms can now perform
quite well as a small DCS, using remote I/O and are sufficiently
reliable that some SCADA systems actually manage closed loop control
over long distances. With the increasing speed of today's processors,
many DCS products have a full line of PLC-like subsystems that weren't
offered when they were initially developed.
In 1993, with the release of IEC-1131, later to become IEC-61131-3,
the industry moved towards increased code standardization with
reusable, hardware-independent control software. For the first time, object-oriented programming
(OOP) became possible within industrial control systems. This led to
the development of both programmable automation controllers (PAC) and
industrial PCs (IPC). These are platforms programmed in the five
standardized IEC languages: ladder logic, structured text, function
block, instruction list and sequential function chart. They can also be
programmed in modern high-level languages such as C or C++.
Additionally, they accept models developed in analytical tools such as MATLAB and Simulink. Unlike traditional PLCs, which use proprietary operating systems, IPCs utilize Windows IoT.
IPC's have the advantage of powerful multi-core processors with much
lower hardware costs than traditional PLCs and fit well into multiple
form factors such as DIN rail mount, combined with a touch-screen as a panel PC,
or as an embedded PC. New hardware platforms and technology have
contributed significantly to the evolution of DCS and SCADA systems,
further blurring the boundaries and changing definitions.
The die from an Intel 8742, an 8-bit microcontroller that includes a CPU running at 12 MHz,128 bytes of RAM, 2048 bytes of EPROM, and I/O in the same chip
Two ATmega microcontrollers
A microcontroller (MCU for microcontroller unit) is a small computer on a single metal-oxide-semiconductor (MOS) integrated circuit chip. In modern terminology, it is similar to, but less sophisticated than, a system on a chip (SoC); a SoC may include a microcontroller as one of its components. A microcontroller contains one or more CPUs (processor cores) along with memory and programmable input/output peripherals. Program memory in the form of ferroelectric RAM, NOR flash or OTP ROM is also often included on chip, as well as a small amount of RAM. Microcontrollers are designed for embedded applications, in contrast to the microprocessors used in personal computers or other general purpose applications consisting of various discrete chips.
Microcontrollers are used in automatically controlled
products and devices, such as automobile engine control systems,
implantable medical devices, remote controls, office machines,
appliances, power tools, toys and other embedded systems. By reducing the size and cost compared to a design that uses a separate microprocessor, memory, and input/output devices, microcontrollers make it economical to digitally control even more devices and processes. Mixed signal
microcontrollers are common, integrating analog components needed to
control non-digital electronic systems. In the context of the internet of things, microcontrollers are an economical and popular means of data collection, sensing and actuating the physical world as edge devices.
Some microcontrollers may use four-bit words and operate at frequencies as low as 4 kHz, for low power consumption (single-digit milliwatts or microwatts). They generally have the ability to retain functionality while waiting for an event such as a button press or other interrupt;
power consumption while sleeping (CPU clock and most peripherals off)
may be just nanowatts, making many of them well suited for long lasting
battery applications. Other microcontrollers may serve
performance-critical roles, where they may need to act more like a digital signal processor (DSP), with higher clock speeds and power consumption.
History
Background
The origins of both the microprocessor and the microcontroller can be traced back to the invention of the MOSFET (metal-oxide-semiconductor field-effect transistor), also known as the MOS transistor. It was invented by Mohamed M. Atalla and Dawon Kahng at Bell Labs in 1959, and first demonstrated in 1960. The same year, Atalla proposed the concept of the MOS integrated circuit, which was an integrated circuit chip fabricated from MOSFETs. By 1964, MOS chips had reached higher transistor density and lower manufacturing costs than bipolar chips. MOS chips further increased in complexity at a rate predicted by Moore's law, leading to large-scale integration (LSI) with hundreds of transistors on a single MOS chip by the late 1960s. The application of MOS LSI chips to computing was the basis for the first microprocessors, as engineers began recognizing that a complete computer processor could be contained on a single MOS LSI chip.
The first multi-chip microprocessors, the Four-Phase Systems AL1 in 1969 and the Garrett AiResearchMP944 in 1970, were developed with multiple MOS LSI chips. The first single-chip microprocessor was the Intel 4004, released on a single MOS LSI chip in 1971. It was developed by Federico Faggin, using his silicon-gate MOS technology, along with Intel engineers Marcian Hoff and Stan Mazor, and Busicom engineer Masatoshi Shima. It was followed by the 4-bitIntel 4040, the 8-bitIntel 8008, and the 8-bit Intel 8080.
All of these processors required several external chips to implement a
working system, including memory and peripheral interface chips. As a
result, the total system cost was several hundred (1970s US) dollars,
making it impossible to economically computerize small appliances. MOS
Technology introduced sub-$100 microprocessors, the 6501 and 6502, with
the chief aim of addressing this economic obstacle, but these
microprocessors still required external support, memory, and peripheral
chips which kept the total system cost in the hundreds of dollars.
Development
One book credits TI
engineers Gary Boone and Michael Cochran with the successful creation
of the first microcontroller in 1971. The result of their work was the TMS 1000,
which became commercially available in 1974. It combined read-only
memory, read/write memory, processor and clock on one chip and was
targeted at embedded systems.
During the early-to-mid-1970s, Japanese electronics manufacturers
began producing microcontrollers for automobiles, including 4-bit MCUs
for in-car entertainment, automatic wipers, electronic locks, and dashboard, and 8-bit MCUs for engine control.
Partly in response to the existence of the single-chip TMS 1000, Intel developed a computer system on a chip optimized for control applications, the Intel 8048, with commercial parts first shipping in 1977. It combined RAM and ROM
on the same chip with a microprocessor. Among numerous applications,
this chip would eventually find its way into over one billion PC
keyboards. At that time Intel's President, Luke J. Valenter, stated that
the microcontroller was one of the most successful products in the
company's history, and he expanded the microcontroller division's budget
by over 25%.
Most microcontrollers at this time had concurrent variants. One had EPROM program memory, with a transparent quartz window in the lid of the package to allow it to be erased by exposure to ultraviolet light. These erasable chips were often used for prototyping. The other variant was either a mask programmed ROM or a PROM
variant which was only programmable once. For the latter, sometimes the
designation OTP was used, standing for "one-time programmable". In an
OTP microcontroller, the PROM was usually of identical type as the
EPROM, but the chip package had no quartz window; because there was no
way to expose the EPROM to ultraviolet light, it could not be erased.
Because the erasable versions required ceramic packages with quartz
windows, they were significantly more expensive than the OTP versions,
which could be made in lower-cost opaque plastic packages. For the
erasable variants, quartz was required, instead of less expensive glass,
for its transparency to ultraviolet light—to which glass is largely
opaque—but the main cost differentiator was the ceramic package itself.
In 1993, the introduction of EEPROM memory allowed microcontrollers (beginning with the Microchip PIC16C84) to be electrically erased quickly without an expensive package as required for EPROM, allowing both rapid prototyping, and in-system programming. (EEPROM technology had been available prior to this time,
but the earlier EEPROM was more expensive and less durable, making it
unsuitable for low-cost mass-produced microcontrollers.) The same year,
Atmel introduced the first microcontroller using Flash memory, a special type of EEPROM. Other companies rapidly followed suit, with both memory types.
Nowadays microcontrollers are cheap and readily available for
hobbyists, with large online communities around certain processors.
Volume and cost
In 2002, about 55% of all CPUs sold in the world were 8-bit microcontrollers and microprocessors.
Over two billion 8-bit microcontrollers were sold in 1997, and according to Semico, over four billion 8-bit microcontrollers were sold in 2006. More recently, Semico has claimed the MCU market grew 36.5% in 2010 and 12% in 2011.
A typical home in a developed country is likely to have only four
general-purpose microprocessors but around three dozen
microcontrollers. A typical mid-range automobile has about 30
microcontrollers. They can also be found in many electrical devices such
as washing machines, microwave ovens, and telephones.
Historically, the 8-bit segment has
dominated the MCU market [..] 16-bit microcontrollers became the
largest volume MCU category in 2011, overtaking 8-bit devices for the
first time that year [..] IC Insights believes the makeup of the MCU
market will undergo substantial changes in the next five years with
32-bit devices steadily grabbing a greater share of sales and unit
volumes. By 2017, 32-bit MCUs are expected to account for 55% of
microcontroller sales [..] In terms of unit volumes, 32-bit MCUs are
expected account for 38% of microcontroller shipments in 2017, while
16-bit devices will represent 34% of the total, and 4-/8-bit designs are
forecast to be 28% of units sold that year.
The 32-bit MCU market is expected to grow rapidly due to
increasing demand for higher levels of precision in embedded-processing
systems and the growth in connectivity using the Internet. [..] In the
next few years, complex 32-bit MCUs are expected to account for over 25%
of the processing power in vehicles.
— IC Insights, MCU Market on Migration Path to 32-bit and ARM-based Devices
Cost to manufacture can be under $0.10 per unit.
Cost has plummeted over time, with the cheapest 8-bit microcontrollers being available for under 0.03 USD in 2018, and some 32-bit microcontrollers around US$1 for similar quantities.
In 2012, following a global crisis—a worst ever annual sales
decline and recovery and average sales price year-over-year plunging
17%—the biggest reduction since the 1980s—the average price for a
microcontroller was US$0.88 ($0.69 for 4-/8-bit, $0.59 for 16-bit, $1.76
for 32-bit).
In 2012, worldwide sales of 8-bit microcontrollers were around $4 billion, while 4-bit microcontrollers also saw significant sales.
In 2015, 8-bit microcontrollers could be bought for $0.311 (1,000 units), 16-bit for $0.385 (1,000 units), and 32-bit for $0.378 (1,000 units, but at $0.35 for 5,000).
In 2018, 8-bit microcontrollers can be bought for $0.03, 16-bit for $0.393 (1,000 units, but at $0.563 for 100 or $0.349 for full reel of 2,000), and 32-bit for $0.503 (1,000 units, but at $0.466 for 5,000). A lower-priced 32-bit microcontroller, in units of one, can be had for $0.891.
In 2018, the low-priced microcontrollers above from 2015 are all
more expensive (with inflation calculated between 2018 and 2015 prices
for those specific units) at: the 8-bit microcontroller can be bought
for $0.319 (1,000 units) or 2.6% higher, the 16-bit one for $0.464 (1,000 units) or 21% higher, and the 32-bit one for $0.503 (1,000 units, but at $0.466 for 5,000) or 33% higher.
A PIC 18F8720 microcontroller in an 80-pin TQFP package
Smallest computer
On 21 June 2018, the "world's smallest computer" was announced by the University of Michigan. The device is a "0.04mm3 16nW wireless and batteryless sensor system with integrated Cortex-M0+
processor and optical communication for cellular temperature
measurement." It "measures just 0.3 mm to a side—dwarfed by a grain of
rice. [...] In addition to the RAM and photovoltaics, the new computing devices have processors and wireless transmitters and receivers.
Because they are too small to have conventional radio antennae, they
receive and transmit data with visible light. A base station provides
light for power and programming, and it receives the data." The device is 1/10th the size of IBM's previously claimed world-record-sized computer from months back in March 2018, which is "smaller than a grain of salt", has a million transistors, costs less than $0.10 to manufacture, and, combined with blockchain technology, is intended for logistics and “crypto-anchors”—”digital fingerprints” applications.
Embedded design
A microcontroller can be considered a self-contained system with a processor, memory and peripherals and can be used as an embedded system.
The majority of microcontrollers in use today are embedded in other
machinery, such as automobiles, telephones, appliances, and peripherals
for computer systems.
While some embedded systems are very sophisticated, many have
minimal requirements for memory and program length, with no operating
system, and low software complexity. Typical input and output devices
include switches, relays, solenoids, LED's, small or custom liquid-crystal displays,
radio frequency devices, and sensors for data such as temperature,
humidity, light level etc. Embedded systems usually have no keyboard,
screen, disks, printers, or other recognizable I/O devices of a personal computer, and may lack human interaction devices of any kind.
Interrupts
Microcontrollers must provide real-time
(predictable, though not necessarily fast) response to events in the
embedded system they are controlling. When certain events occur, an interrupt system can signal the processor to suspend processing the current instruction sequence and to begin an interrupt service routine
(ISR, or "interrupt handler") which will perform any processing
required based on the source of the interrupt, before returning to the
original instruction sequence. Possible interrupt sources are device
dependent, and often include events such as an internal timer overflow,
completing an analog to digital conversion, a logic level change on an
input such as from a button being pressed, and data received on a
communication link. Where power consumption is important as in battery
devices, interrupts may also wake a microcontroller from a low-power
sleep state where the processor is halted until required to do something
by a peripheral event.
Programs
Typically
micro-controller programs must fit in the available on-chip memory,
since it would be costly to provide a system with external, expandable
memory. Compilers and assemblers are used to convert both high-level and assembly language codes into a compact machine code for storage in the micro-controller's memory. Depending on the device, the program memory may be permanent, read-only memory that can only be programmed at the factory, or it may be field-alterable flash or erasable read-only memory.
Manufacturers have often produced special versions of their micro-controllers in order to help the hardware and software development of the target system. Originally these included EPROM versions that have a "window" on the top of the device through which program memory can be erased by ultraviolet
light, ready for reprogramming after a programming ("burn") and test
cycle. Since 1998, EPROM versions are rare and have been replaced by EEPROM and flash, which are easier to use (can be erased electronically) and cheaper to manufacture.
Other versions may be available where the ROM is accessed as an
external device rather than as internal memory, however these are
becoming rare due to the widespread availability of cheap
microcontroller programmers.
The use of field-programmable devices on a micro controller may allow field update of the firmware
or permit late factory revisions to products that have been assembled
but not yet shipped. Programmable memory also reduces the lead time
required for deployment of a new product.
Where hundreds of thousands of identical devices are required,
using parts programmed at the time of manufacture can be economical.
These "mask programmed" parts have the program laid down in the same way as the logic of the chip, at the same time.
A customized micro-controller incorporates a block of digital
logic that can be personalized for additional processing capability, peripherals and interfaces that are adapted to the requirements of the application. One example is the AT91CAP from Atmel.
Other microcontroller features
Microcontrollers
usually contain from several to dozens of general purpose input/output
pins (GPIO). GPIO pins are software configurable to either an input or
an output state. When GPIO pins are configured to an input state, they
are often used to read sensors or external signals. Configured to the
output state, GPIO pins can drive external devices such as LEDs or
motors, often indirectly, through external power electronics.
Many embedded systems need to read sensors that produce analog signals. This is the purpose of the analog-to-digital converter
(ADC). Since processors are built to interpret and process digital
data, i.e. 1s and 0s, they are not able to do anything with the analog
signals that may be sent to it by a device. So the analog to digital
converter is used to convert the incoming data into a form that the
processor can recognize. A less common feature on some microcontrollers
is a digital-to-analog converter (DAC) that allows the processor to output analog signals or voltage levels.
In addition to the converters, many embedded microprocessors
include a variety of timers as well. One of the most common types of
timers is the programmable interval timer
(PIT). A PIT may either count down from some value to zero, or up to
the capacity of the count register, overflowing to zero. Once it reaches
zero, it sends an interrupt to the processor indicating that it has
finished counting. This is useful for devices such as thermostats, which
periodically test the temperature around them to see if they need to
turn the air conditioner on, the heater on, etc.
A universal asynchronous receiver/transmitter
(UART) block makes it possible to receive and transmit data over a
serial line with very little load on the CPU. Dedicated on-chip hardware
also often includes capabilities to communicate with other devices
(chips) in digital formats such as Inter-Integrated Circuit (I²C), Serial Peripheral Interface (SPI), Universal Serial Bus (USB), and Ethernet.
Micro-controllers may not implement an external address or data bus
as they integrate RAM and non-volatile memory on the same chip as the
CPU. Using fewer pins, the chip can be placed in a much smaller, cheaper
package.
Integrating the memory and other peripherals on a single chip and
testing them as a unit increases the cost of that chip, but often
results in decreased net cost of the embedded system as a whole. Even if
the cost of a CPU that has integrated peripherals is slightly more than
the cost of a CPU and external peripherals, having fewer chips
typically allows a smaller and cheaper circuit board, and reduces the
labor required to assemble and test the circuit board, in addition to
tending to decrease the defect rate for the finished assembly.
A micro-controller is a single integrated circuit, commonly with the following features:
This integration drastically reduces the number of chips and the amount of wiring and circuit board
space that would be needed to produce equivalent systems using separate
chips. Furthermore, on low pin count devices in particular, each pin
may interface to several internal peripherals, with the pin function
selected by software. This allows a part to be used in a wider variety
of applications than if pins had dedicated functions.
Micro-controllers have proved to be highly popular in embedded systems since their introduction in the 1970s.
Some microcontrollers use a Harvard architecture:
separate memory buses for instructions and data, allowing accesses to
take place concurrently. Where a Harvard architecture is used,
instruction words for the processor may be a different bit size than the
length of internal memory and registers; for example: 12-bit
instructions used with 8-bit data registers.
The decision of which peripheral to integrate is often difficult.
The microcontroller vendors often trade operating frequencies and
system design flexibility against time-to-market requirements from their
customers and overall lower system cost. Manufacturers have to balance
the need to minimize the chip size against additional functionality.
Microcontroller architectures vary widely. Some designs include
general-purpose microprocessor cores, with one or more ROM, RAM, or I/O
functions integrated onto the package. Other designs are purpose built
for control applications. A micro-controller instruction set usually has
many instructions intended for bit manipulation (bit-wise operations) to make control programs more compact.
For example, a general purpose processor might require several
instructions to test a bit in a register and branch if the bit is set,
where a micro-controller could have a single instruction to provide that
commonly required function.
Microcontrollers traditionally do not have a math coprocessor, so floating point
arithmetic is performed by software. However, some recent designs do
include an FPU and DSP optimized features. An example would be
Microchip's PIC32 MIPS based line.
Programming environments
Microcontrollers were originally programmed only in assembly language, but various high-level programming languages, such as C, Python and JavaScript, are now also in common use to target microcontrollers and embedded systems. Compilers
for general purpose languages will typically have some restrictions as
well as enhancements to better support the unique characteristics of
microcontrollers. Some microcontrollers have environments to aid
developing certain types of applications. Microcontroller vendors often
make tools freely available to make it easier to adopt their hardware.
Microcontrollers with specialty hardware may require their own non-standard dialects of C, such as SDCC for the 8051,
which prevent using standard tools (such as code libraries or static
analysis tools) even for code unrelated to hardware features. Interpreters may also contain nonstandard features, such as MicroPython, although a fork, CircuitPython, has looked to move hardware dependencies to libraries and have the language adhere to a more CPython standard.
Interpreter firmware is also available for some microcontrollers. For example, BASIC on the early microcontrollers Intel8052; BASIC and FORTH on the Zilog Z8as well as some modern devices. Typically these interpreters support interactive programming.
Simulators
are available for some microcontrollers. These allow a developer to
analyze what the behavior of the microcontroller and their program
should be if they were using the actual part. A simulator
will show the internal processor state and also that of the outputs, as
well as allowing input signals to be generated. While on the one hand
most simulators will be limited from being unable to simulate much other
hardware in a system, they can exercise conditions that may otherwise
be hard to reproduce at will in the physical implementation, and can be
the quickest way to debug and analyze problems.
Recent microcontrollers are often integrated with on-chip debug circuitry that when accessed by an in-circuit emulator (ICE) via JTAG, allow debugging of the firmware with a debugger.
A real-time ICE may allow viewing and/or manipulating of internal
states while running. A tracing ICE can record executed program and MCU
states before/after a trigger point.
Types
As of 2008, there are several dozen microcontroller architectures and vendors including:
Many others exist, some of which are used in very narrow range of
applications or are more like applications processors than
microcontrollers. The microcontroller market is extremely fragmented,
with numerous vendors, technologies, and markets. Note that many vendors
sell or have sold multiple architectures.
Interrupt latency
In contrast to general-purpose computers, microcontrollers used in embedded systems often seek to optimize interrupt latency
over instruction throughput. Issues include both reducing the latency,
and making it be more predictable (to support real-time control).
When an electronic device causes an interrupt, during the context switch
the intermediate results (registers) have to be saved before the
software responsible for handling the interrupt can run. They must also
be restored after that interrupt handler is finished. If there are more processor registers,
this saving and restoring process may take more time, increasing the
latency. (If an ISR does not require the use of some registers, it may
simply leave them alone rather than saving and restoring them, so in
that case those registers are not involved with the latency.) Ways to
reduce such context/restore latency include having relatively few
registers in their central processing units (undesirable because it
slows down most non-interrupt processing substantially), or at least
having the hardware not save them all (this fails if the software then
needs to compensate by saving the rest "manually"). Another technique
involves spending silicon gates on "shadow registers": One or more
duplicate registers used only by the interrupt software, perhaps
supporting a dedicated stack.
Other factors affecting interrupt latency include:
Cycles needed to complete current CPU activities. To minimize
those costs, microcontrollers tend to have short pipelines (often three
instructions or less), small write buffers, and ensure that longer
instructions are continuable or restartable. RISC
design principles ensure that most instructions take the same number of
cycles, helping avoid the need for most such continuation/restart
logic.
The length of any critical section
that needs to be interrupted. Entry to a critical section restricts
concurrent data structure access. When a data structure must be accessed
by an interrupt handler, the critical section must block that
interrupt. Accordingly, interrupt latency is increased by however long
that interrupt is blocked. When there are hard external constraints on
system latency, developers often need tools to measure interrupt
latencies and track down which critical sections cause slowdowns.
One common technique just blocks all interrupts for the duration
of the critical section. This is easy to implement, but sometimes
critical sections get uncomfortably long.
A more complex technique just blocks the interrupts that may trigger
access to that data structure. This is often based on interrupt
priorities, which tend to not correspond well to the relevant system
data structures. Accordingly, this technique is used mostly in very
constrained environments.
Processors may have hardware support for some critical sections.
Examples include supporting atomic access to bits or bytes within a
word, or other atomic access primitives like the LDREX/STREX exclusive access primitives introduced in the ARMv6 architecture.
Interrupt nesting. Some microcontrollers allow higher priority
interrupts to interrupt lower priority ones. This allows software to
manage latency by giving time-critical interrupts higher priority (and
thus lower and more predictable latency) than less-critical ones.
Trigger rate. When interrupts occur back-to-back, microcontrollers may avoid an extra context save/restore cycle by a form of tail call optimization.
Lower end microcontrollers tend to support fewer interrupt latency controls than higher end ones.
Memory technology
Two
different kinds of memory are commonly used with microcontrollers, a
non-volatile memory for storing firmware and a read-write memory for
temporary data.
Data
From the
earliest microcontrollers to today, six-transistor SRAM is almost always
used as the read/write working memory, with a few more transistors per
bit used in the register file. FRAM or MRAM could potentially replace it as it is 4 to 10 times denser which would make it more cost effective.
In addition to the SRAM, some microcontrollers also have internal
EEPROM for data storage; and even ones that do not have any (or not
enough) are often connected to external serial EEPROM chip (such as the BASIC Stamp) or external serial flash memory chip.
A few recent microcontrollers beginning in 2003 have "self-programmable" flash memory.
Firmware
The earliest microcontrollers used mask ROM to store firmware. Later microcontrollers (such as the early versions of the Freescale 68HC11 and early PIC microcontrollers) had EPROM
memory, which used a translucent window to allow erasure via UV light,
while production versions had no such window, being OTP
(one-time-programmable). Firmware updates were equivalent to replacing
the microcontroller itself, thus many products were not upgradeable.
Motorola MC68HC805was the first microcontroller to use EEPROM to store the firmware. EEPROM microcontrollers became more popular in 1993 when Microchip introduced PIC16C84 and Atmel introduced an 8051-core microcontroller that was first one to use NOR Flash memory to store the firmware.
Today's microcontrollers almost exclusively use flash memory, with a
few models using FRAM, and some ultra-low-cost parts still use OTP or
Mask-ROM.
A real-time operating system (RTOS) is an operating system (OS) intended to serve real-time
applications that process data as it comes in, typically without buffer
delays. Processing time requirements (including any OS delay) are
measured in tenths of seconds or shorter increments of time. A real-time
system is a time bound system which has well defined fixed time
constraints. Processing must be done within the defined constraints or
the system will fail. They either are event driven
or time sharing. Event driven systems switch between tasks based on
their priorities while time sharing systems switch the task based on
clock interrupts. Most RTOSs use a pre-emptive scheduling algorithm.
A key characteristic of an RTOS is the level of its consistency
concerning the amount of time it takes to accept and complete an
application's task; the variability is 'jitter'. A 'hard' real-time operating system has less jitter than a 'soft'
real-time operating system. The chief design goal is not high throughput, but rather a guarantee of a soft or hard
performance category. An RTOS that can usually or generally meet a
deadline is a soft real-time OS, but if it can meet a deadline deterministically it is a hard real-time OS.
An RTOS has an advanced algorithm for scheduling.
Scheduler flexibility enables a wider, computer-system orchestration of
process priorities, but a real-time OS is more frequently dedicated to a
narrow set of applications. Key factors in a real-time OS are minimal interrupt latency and minimal thread switching latency;
a real-time OS is valued more for how quickly or how predictably it can
respond than for the amount of work it can perform in a given period of
time.
Event-driven – switches tasks only when an event of higher priority needs servicing; called preemptive priority, or priority scheduling.
Time-sharing – switches tasks on a regular clocked interrupt, and on events; called round robin.
Time sharing designs switch tasks more often than strictly needed, but give smoother multitasking, giving the illusion that a process or user has sole use of a machine.
Early CPU designs needed many cycles to switch tasks during which the CPU could do nothing else useful. For example, with a 20 MHz 68000 processor (typical of the late 1980s), task switch times are roughly 20 microseconds. In contrast, a 100 MHz ARM CPU (from 2008) switches in less than 3 microseconds. Because switching took so long, early OSes tried to minimize wasting CPU time by avoiding unnecessary task switching.
Scheduling
In typical designs, a task has three states:
Running (executing on the CPU);
Ready (ready to be executed);
Blocked (waiting for an event, I/O for example).
Most tasks are blocked or ready most of the time because generally only one task can run at a time per CPU.
The number of items in the ready queue can vary greatly, depending on
the number of tasks the system needs to perform and the type of
scheduler that the system uses. On simpler non-preemptive but still
multitasking systems, a task has to give up its time on the CPU to other
tasks, which can cause the ready queue to have a greater number of
overall tasks in the ready to be executed state (resource starvation).
Usually the data structure of the ready list in the scheduler is
designed to minimize the worst-case length of time spent in the
scheduler's critical section, during which preemption is inhibited, and,
in some cases, all interrupts are disabled, but the choice of data
structure depends also on the maximum number of tasks that can be on the
ready list.
If there are never more than a few tasks on the ready list, then a doubly linked list
of ready tasks is likely optimal. If the ready list usually contains
only a few tasks but occasionally contains more, then the list should be
sorted by priority. That way, finding the highest priority task to run
does not require iterating through the entire list. Inserting a task
then requires walking the ready list until reaching either the end of
the list, or a task of lower priority than that of the task being
inserted.
Care must be taken not to inhibit preemption during this search.
Longer critical sections should be divided into small pieces. If an
interrupt occurs that makes a high priority task ready during the
insertion of a low priority task, that high priority task can be
inserted and run immediately before the low priority task is inserted.
The critical response time, sometimes called the flyback time, is
the time it takes to queue a new ready task and restore the state of
the highest priority task to running. In a well-designed RTOS, readying a
new task will take 3 to 20 instructions per ready-queue entry, and
restoration of the highest-priority ready task will take 5 to 30
instructions.
In more advanced systems, real-time tasks share computing
resources with many non-real-time tasks, and the ready list can be
arbitrarily long. In such systems, a scheduler ready list implemented as
a linked list would be inadequate.
Algorithms
Some commonly used RTOS scheduling algorithms are:
A multitasking operating system like Unix
is poor at real-time tasks. The scheduler gives the highest priority to
jobs with the lowest demand on the computer, so there is no way to
ensure that a time-critical job will have access to enough resources.
Multitasking systems must manage sharing data and hardware resources
among multiple tasks. It is usually unsafe for two tasks to access the
same specific data or hardware resource simultaneously. There are three common approaches to resolve this problem:
Temporarily masking/disabling interrupts
General-purpose operating systems usually do not allow user programs to mask (disable) interrupts, because the user program could control the CPU for as long as it wishes. Some modern CPUs do not allow user mode
code to disable interrupts as such control is considered a key
operating system resource. Many embedded systems and RTOSs, however,
allow the application itself to run in kernel mode for greater system call
efficiency and also to permit the application to have greater control
of the operating environment without requiring OS intervention.
On single-processor systems, an application running in kernel
mode and masking interrupts is the lowest overhead method to prevent
simultaneous access to a shared resource. While interrupts are masked
and the current task does not make a blocking OS call, the current task
has exclusive use of the CPU since no other task or interrupt can take control, so the critical section
is protected. When the task exits its critical section, it must unmask
interrupts; pending interrupts, if any, will then execute. Temporarily
masking interrupts should only be done when the longest path through the
critical section is shorter than the desired maximum interrupt latency.
Typically this method of protection is used only when the critical
section is just a few instructions and contains no loops. This method is
ideal for protecting hardware bit-mapped registers when the bits are
controlled by different tasks.
Mutexes
When
the shared resource must be reserved without blocking all other tasks
(such as waiting for Flash memory to be written), it is better to use
mechanisms also available on general-purpose operating systems, such as a
mutex
and OS-supervised interprocess messaging. Such mechanisms involve
system calls, and usually invoke the OS's dispatcher code on exit, so
they typically take hundreds of CPU instructions to execute, while
masking interrupts may take as few as one instruction on some
processors.
A (non-recursive) mutex is either locked or unlocked. When a task has locked the mutex, all other tasks must wait for the mutex to be unlocked by its owner
- the original thread. A task may set a timeout on its wait for a
mutex. There are several well-known problems with mutex based designs
such as priority inversion and deadlocks.
In priority inversion
a high priority task waits because a low priority task has a mutex, but
the lower priority task is not given CPU time to finish its work. A
typical solution is to have the task that owns a mutex at, or 'inherit,'
the priority of the highest waiting task. But this simple approach gets
more complex when there are multiple levels of waiting: task A waits for a mutex locked by task B, which waits for a mutex locked by task C.
Handling multiple levels of inheritance causes other code to run in
high priority context and thus can cause starvation of medium-priority
threads.
In a deadlock,
two or more tasks lock mutex without timeouts and then wait forever for
the other task's mutex, creating a cyclic dependency. The simplest
deadlock scenario occurs when two tasks alternately lock two mutex, but
in the opposite order. Deadlock is prevented by careful design.
Message passing
The other approach to resource sharing is for tasks to send messages in an organized message passing
scheme. In this paradigm, the resource is managed directly by only one
task. When another task wants to interrogate or manipulate the resource,
it sends a message to the managing task. Although their real-time
behavior is less crisp than semaphore
systems, simple message-based systems avoid most protocol deadlock
hazards, and are generally better-behaved than semaphore systems.
However, problems like those of semaphores are possible. Priority
inversion can occur when a task is working on a low-priority message and
ignores a higher-priority message (or a message originating indirectly
from a high priority task) in its incoming message queue. Protocol
deadlocks can occur when two or more tasks wait for each other to send
response messages.
Interrupt handlers and the scheduler
Since
an interrupt handler blocks the highest priority task from running, and
since real-time operating systems are designed to keep thread latency
to a minimum, interrupt handlers are typically kept as short as
possible. The interrupt handler defers all interaction with the hardware
if possible; typically all that is necessary is to acknowledge or
disable the interrupt (so that it won't occur again when the interrupt
handler returns) and notify a task that work needs to be done. This can
be done by unblocking a driver task through releasing a semaphore,
setting a flag or sending a message. A scheduler often provides the
ability to unblock a task from interrupt handler context.
An OS maintains catalogues of objects it manages such as threads,
mutexes, memory, and so on. Updates to this catalogue must be strictly
controlled. For this reason it can be problematic when an interrupt
handler calls an OS function while the application is in the act of also
doing so. The OS function called from an interrupt handler could find
the object database to be in an inconsistent state because of the
application's update. There are two major approaches to deal with this
problem: the unified architecture and the segmented architecture. RTOSs
implementing the unified architecture solve the problem by simply
disabling interrupts while the internal catalogue is updated. The
downside of this is that interrupt latency increases, potentially losing
interrupts. The segmented architecture does not make direct OS calls
but delegates the OS related work to a separate handler. This handler
runs at a higher priority than any thread but lower than the interrupt
handlers. The advantage of this architecture is that it adds very few
cycles to interrupt latency. As a result, OSes which implement the
segmented architecture are more predictable and can deal with higher
interrupt rates compared to the unified architecture.
Similarly the System Management Mode
on x86 compatible Hardware can take too much time before it returns
control to the operating system. It is generally wrong to write
real-time software for x86 Hardware.
Memory allocation
Memory allocation is more critical in a real-time operating system than in other operating systems.
First, for stability there cannot be memory leaks
(memory that is allocated but not freed after use). The device should
work indefinitely, without ever needing a reboot. For this reason, dynamic memory allocation is frowned upon. Whenever possible, all required memory allocation is specified statically at compile time.
Another reason to avoid dynamic memory allocation is memory
fragmentation. With frequent allocation and releasing of small chunks of
memory, a situation may occur where available memory is divided into
several sections and the RTOS is incapable of allocating a large enough
continuous block of memory, although there is enough free memory.
Secondly, speed of allocation is important. A standard memory allocation
scheme scans a linked list of indeterminate length to find a suitable
free memory block, which is unacceptable in an RTOS since memory allocation has to occur within a certain amount of time.
Because mechanical disks have much longer and more unpredictable
response times, swapping to disk files is not used for the same reasons
as RAM allocation discussed above.
