This Domain Context Model represents the framework's embedded systems concepts.
Major concepts and connections are:
- Firmware is the name for software which runs on an embedded system
- A firmware binary is a compiled software package
- Other names are "image" or "payload"
- A typical firmware binary consists of:
- Application logic, which is unique to each system's goals and responsibilities
- Libraries and utilities, which provide reusable support functionality
- Subsystems, which encapsulate a standalone functional operation
- Drivers, which allow software to interact with hardware components
- An RTOS may optionally be used to provide threading and minimal OS support
- A firmware binary runs on a Hardware Platform (aka PCB/board), which is composed of:
- A firmware binary is produced by a build system
- A CI server uses the build system to create and store firmware images
- A CI server often runs tests to check the output quality
- The term virtual refers to an abstract interface which generalizes the underlying functionality
- e.g., virtual hardware platform, virtual RTOS, virtual processor
Figure 1. Domain Context Model for Embedded Framework. |
- Application
- Binary
- Build system
- CI server
- Circuit
- Driver
- Firmware
- HAL
- Hardware Platform
- Library
- Processor
- Protocol
- RTOS
- Subsystems
- Utilities
- Virtual
- An "application" is a software program
- The application logic controls how an embedded device operates
- The application logic is unique to each system's goals and responsibilities
- In most cases, the business's core IP is contained within the application logic
- A firmware binary is a compiled software package that is runnable on an embedded system
- Other common terms are a firmware "image" or firmware "payload"
- A typical firmware binary consists of:
- Application logic
- Libraries and utilities
- Subsystems
- Drivers
- The output of a build system's compilation process is a firmware binary
- The build system contains rules for assembling a set of source code files into a binary
- The build system consists of the compiler/linker, rules for compiling the project, and associated tools which are used during the assembly process
- The output of the compilation process is a firmware binary
- The build system will also compile unit tests
- CI = Continuous Integration
- Also known as a "build server" or "integration server"
- A CI server checks out a copy of the firmware source code and uses the build system to create and store firmware binaries
- A CI server often runs tests to check the output quality
- A CI server will often track metrics for a build over time, such as:
- Warnings
- Build Failures
- Test Failures
- A CI server can be configured to report results to another server
- Often, code management services will require a build to compile correctly and pass all tests before a merge request is approved
- A circuit is a set of electrical components which are interconnected to provide a specific function
- Hardware platforms, aka circuit boards, are composed of a processor and corresponding circuits
Circuits can be Integrated Circuits (ICs), which are standalone components on a circuit board:
A circuit in which all or some of the circuit elements are inseparably associated and electrically interconnected so that it is considered to be indivisible for the purposes of construction and commerce.
Circuits can also be made of discrete components, and may be classified as active or passive.
Active circuits:
Active circuits are those which can provide gain, either voltage gain or current gain.
An active circuit is a circuit which contains at least one of these (common) active devices: transistors (bipolar or FET types), operational amplifiers (opamps), OTAs (Operational Transconductance Amplifiers) or vacuum tubes (of the amplifying type, mostly triodes and pentodes). There are some other variants of active devices (e.g., MESFETs) but they are less common).
Passive circuits:
Passive circuits are those which cannot or do not provide any gain.
A circuit without an active device is a passive circuit. The active and passive terms are usually applied to filters.
Further Reading:
A driver is a software module which encapsulates interactions with a processor's peripheral or a circuit.
A driver typically deals directly with hardware (in the case of the HAL, or hardware abstraction layer) or with other drivers (such as an accelerometer driver which communicates to the part using a SPI bus driver).
Each electrical circuit requires its own device driver. Interfaces can be written in a generic manner, meaning that different classes of drivers are implemented to the same interface. With a generic driver interface, drivers of the same class are interchangeable (e.g., you can swap one accelerometer with another).
- Firmware is the name for software which runs on an embedded system
- Firmware refers either to the set of source code, the class of program (i.e., software for embedded systems), or the binary output
- HAL = Hardware Abstraction Layer
- A specialization of the driver concept
- A driver that deals directly with hardware (e.g., a processor peripheral) is a HAL driver
- HAL drivers contains more interfaces and responsibilites than generic drivers
- Often requires a memory-mapped register address which corresponds to the device's hardware interface
- May or may not have DMA support
- May or may not have interrupt support
- May or may not have configurable clocks
- May or may not support error conditions and recovery mechanisms
- Also commonly referred to as "board" or "PCB" (Printed circuit board)
- A hardware platform is the total hardware system which the firmware application is targeted board
- Composed of:
- The hardware platform may be a complete design, such as a printed circuit board
- The hardware platform may also be a loosely connected design, involving multiple boards/components connected via wires or cabling
- The firmware binary runs on the hardware platform
- A software module which provides a set of functionality
- Reusable across projects
- Typically contains a cohesive responsibility or theme, such as "fixed-point mathematics", "logging", or "version"
- Differ from Subsystems in that they are not typically active modules that handle a specific system responsibility
Further Reading:
- A processor is an integrated circuit that contains all the functions of a central processing unit of a computer
- A processor has an architecture, which is the underlying abstract model that the processor implements. The architecture includes:
- Machine language (assembly)
- Register mapping, addressing, and functionality
- Memory locations and offsets
- Complex instructions, such as DMA, caching, floating-point arithemetic
- A processor also has a vendor, which is the company that designed and implemented the processor
- Each vendor has particular style of implementation, feature sets, and peripheral implementations
- Each vendor organizes processors into families, which are processor lines that contain similar functionality at various
- A processor may or may not offer a set of hardware peripherals, which are integrated into the chip and usable through Special Function Register (SFR) interfaces
- These hardware devices contain memory-mapped structures which are used to interact with the peripheral hardware
- These may be sensors, communication busses, timers, etc.
- Other common terms: microprocessor, microcontroller, system on a chip (SoC)
- Microprocessor typically has fewer (or no) peripheral devices
- SoCs typically have a wide array of integrated peripherals
- A firmware binary runs on the processor
Further Reading:
- Wikipedia: Microprocessor
- Wikipedia: CPU
- Wikipedia: Instruction Set Architecture
- Wikipedia: Microarchitecture
TBD
- RTOS = Real-time Operating System
- An RTOS may optionally be used to provide threading and minimal OS support
- Many RTOSes offer preemptive multitasking support, to ensure that the highest priority task is always executing
- RTOSes often provide stricter timing and latency guarantees compared to more traditional operating systems
- A subsystem encapsulates a standalone functional operation within a larger software system
- Subsystems are decompositions of systems
- Each subsystem should have a singular (albeit complex) purpose
- Subsystems are typically active in nature, requiring their own threads or regular processing time
- Example subsystems include: command line, system power management, over-the-air (OTA) updater, firmware updater
- Utilities represent cross-cutting constructs that can be used without creating specific platform dependencies
- A utility is a specialization of a library
- The scope is typically much smaller: a single class or single file which provides a re-usable piece of functionality
- Example utilities include static queues, buffer pools, dispatch queues, or static
std::function
alternative
- The term virtual refers to an abstract interface which generalizes the underlying functionality
- e.g., virtual hardware platform, virtual RTOS, virtual processor
- Higher-level software is implemented to virtual interfaces in order to decouple the software from the underlying hardware