Embedded system software

terminologies
Kernel :
• The kernel is the fundamental part of an operating system.
• It is responsible for managing the resources and the communication
between hardware and software components.
• The kernel offers hardware abstraction to the applications and
provides secure access to the system memory.
• It also includes an interrupt handler that handles all requests or
completed I/O operations.
•

Bootloader

A bootloader is a small piece of software that executes soon after you power up a computer.

On a desktop PC, the bootloader resides on the master boot record (MBR) of the hard drive, and is
executed after the PC BIOS performs various system initializations.

The bootloader then passes system information to the kernel (for instance, the hard drive partition to
mount as root) and then executes the kernel.

In an embedded system, the role of the bootloader is more complicated, since an embedded system does
not have a BIOS to perform the initial system configuration.

The low-level initialization of the microprocessor, memory controllers, and other board-specific hardware
varies from board to board and CPU to CPU.

These initializations must be performed before a kernel image can execute.

 Kernel modules
• Modules are pieces of code that can be loaded and unloaded into the kernel upon
demand. They extend the functionality of the kernel without requiring a system
reboot.
• For example, one type of module is the device driver, which allows the kernel to
access hardware connected to the system.
• Without these modules, Linux developers would have to build monolithic kernels
and add new functionality directly into the kernel image.
• The result would be a large, cumbersome kernel. Another disadvantage of working
without a kernel module is that you would have to rebuild and reboot the kernel
every time you add new functionality.
• In embedded systems, where functionality can be activated depending on the
needs, kernel modules become a very effective way of adding features without
enlarging the kernel image size.
 Root file system

• Operating systems normally rely on a set of files and directories.

• The root file system is the top of the hierarchical file tree.
• It contains the files and directories critical for system operation,
including the device directory and programs for booting the system.
• The root file system also contains mount points where other file
systems can be mounted to connect to the root file system
hierarchy.
Applications
• Software applications are programs that employ the capabilities and
resources of a computer to do a particular task.
• Applications make use of hardware devices by communicating with
device drivers, which are part of the kernel.
Cross-compilation

• If you generate code for an embedded target on a development

system with a different microprocessor architecture, you need a
cross-development environment.
• A cross-development compiler is one that executes in the
development system (for example, an x86 PC), but generates code
that executes in a different processor (for example, if the target is
ARM).
Assembler-
• A software development tool that translates human-readable assembly language
programs into machine-readable code that the target processor can understand and
execute.

Assembly language-
• A human-writable form of a processor's native instruction set. In its typical form,
each line of assembly code represents a single CPU instruction. The human-
readable representation of each opcode is called a mnemonic.
Compiler
A software-development tool that translates high-level language programs into the
machine-language instructions that a particular processor can understand and execute.
Cross-compiler
• A compiler that runs on a different platform from the one for which it
produces object code. Often even the processor architecture/family of
the host and target platforms differ.
Firmware
• Executable software that is stored within a ROM.
• USAGE: This term is interchangeable with embedded software and
sometimes is used even when the executable is not stored in ROM.
Glue logic
• The address decoding and other messy circuitry (or programmable
logic) that ties together a system. It's called glue logic because it's
what holds the entire system together.
Debugger
• A tool used to test and debug software.
• A typical remote debugger runs on a host computer and connects to the target through a serial port or over
a network.
• Using the debugger, you can download software to the target for immediate execution. You can also set
breakpoints in the code and examine the contents of specific memory locations and registers.
Device driver
• A software module that hides the details of a particular peripheral and provides a high-level programming
interface to it.
• Each device driver is typically a piece of operating system-specific software that makes it possible for
application software to attach to, read and write data from, and change the behavior of the peripheral
device.
• The more complex the operating system environment, the more likely it is that the device driver code will
have to conform to a certain high-level API. For example, Windows and Unix both require every network
device driver to conform to a common API.
Executable
• A file containing object code that is ready for execution on the target. All that remains is to place the
object code into a ROM or download it via a debugging tool.
Linker

A software development tool that accepts one

or more object files as input and outputs a
relocatable program.

The linker is thus run after all of the source

files have been compiled and assembled into
object files.
locator
• A software development tool that assigns physical addresses to a
relocatable program.
• This is the last step in preparing software for execution by an
embedded system.
• The resulting file is called an executable. In some cases, the locator's
functionality is built into the linker.
object code
• A set of processor-readable opcodes and data.
• The output of compilers and assemblers and the input and output of a
linker are files containing object code.
• However, there are a variety of standardized and proprietary object
file formats, meaning that development tools from one vendor can
only rarely read the object code produced by those of another.
object file
• A file containing object code; in particular, the output of a compiler or
assembler.
• Most object files begin with a symbol table, which is followed by
intermixed segments of code and data.
Operating system
• A piece of software that makes multitasking possible.
• An operating system typically consists of a set of system calls and a
periodic clock tick ISR.
• The operating system is responsible for deciding which process or
thread should be using the processor at any given time and for
controlling access to shared resources.
profiler
• A software development tool that collects and reports execution
statistics for your programs.
• These statistics include the number of calls to each subroutine and the
total amount of time spent within each.
• This data can be used to learn which subroutines are the most critical
and, therefore, demand the greatest code efficiency.
• Unfortunately, such technology is not often available in the remote
debugging environment typical of embedded systems development.
scheduler
• The part of an operating system that decides which task to run next.
• The scheduler's decision is based on the state of each task, the relative
priorities of those that are ready to run, and the specific scheduling
algorithm implemented.
shareware
• Software that is distributed for free, but with a payment expectation.
simulator
• A debugging tool that runs on the host and pretends to be the target
processor.
• A simulator can be used to test pieces of the embedded software before
the embedded hardware is available.
• Unfortunately, attempts to simulate interactions with complex
peripherals are often more trouble than they are worth.
source code
• A program (or part of one) in its original, human-readable form. Any file
containing C, C++, Java, even assembly-language code is source code.
stack
• A list in which elements are always added and removed from the (conceptual)
end.
• A last-in, first-out queue. Stacks are one of the four basic kinds of queues or
lists.
• They are used most frequently to keep track of hierarchically nested processes.
• They are common in both application- and system-level software. Any
processor that implements a call instruction must also support some kind of
hardware stack (the run-time stack).
• Compilers rely on the run-time stack to support function calls and argument
passing.
stack frame
• An area of the stack associated with a particular function call.

startup code
• A piece of assembly language code that prepares the way for software
written in a high_level_language.
• Most cross-compilers come with startup code that you can modify,
compile, and link with your embedded programs.
• Startup code usually initializes code and data segments, safes I/O, and
sets up chip selects and wait states.
target
• The embedded system under development.
Unified Modeling Language
• A standardized visual notation for communication about system
specifications and design details. Abbreviated UML.
user mode
• A state in which a processor will not execute some of its instructions.
For example, while in user mode, it might not be possible to disable
interrupts. Contrast with kernel mode.
watchdog timer
• A fail-safe mechanism that intervenes if a system stops functioning.
Abbreviated WDT. A hardware timer that is periodically reset by
software.
• If the software crashes or hangs, the watchdog timer will expire, and
the entire system will be reset automatically