Module 1 embedded software essentials

Summarized by Saad Elkheety SaadElkheety@gmail.com
Introduction to Embedded Systems
Software and Development Environments
Contents
1 Module 1: Embedded Software Essentials...........................................................................................2
1.1 Introduction to Embedded System...............................................................................................2
1.1.1 Embedded Systems Software Design....................................................................................2
1.1.2 Software requirements.........................................................................................................2
1.1.3 What Embedded System is? .................................................................................................2
1.1.4 Limited Resources.................................................................................................................2
1.1.5 The development platform components..............................................................................3
1.1.6 Microcontroller.....................................................................................................................3
1.2 Embedded Software Engineering .................................................................................................4
1.2.1 Flow Diagram: .......................................................................................................................5
1.2.2 Software Block Diagram:.......................................................................................................5
1.2.3 Five main development tools:...............................................................................................7
1.2.4 The principles of high quality software.................................................................................7
1.2.5 Embedded software languages:............................................................................................7
1.3 Software Configuration Management..........................................................................................8
1.3.1 Legacy systems....................................................................................................................10
1.3.2 Task management and defect tracking...............................................................................11
1.4 C Standardization and Team Coding Standards..........................................................................11
1.4.1 C-Programming Standards..................................................................................................11
1.4.2 Coding Standard..................................................................................................................11
1.4.3 MISRA (Motor Industry Software Reliability Association) ..................................................12
1.5 Development Environments Overview.......................................................................................12
1.5.1 Command line.....................................................................................................................12
1.5.2 Integrated development environment ...............................................................................12
1.6 Development Kits and Documentation.......................................................................................13
1.6.1 The Selector Guide..............................................................................................................13
1.6.2 The product brief ................................................................................................................14
1.6.3 Datasheet............................................................................................................................14

1.6.4 Family Technical Reference Manual ...................................................................................15
1.6.5 Chip Errata...........................................................................................................................15
1.6.6 Development kits................................................................................................................16
1.7 Version Control Systems.............................................................................................................17
1.7.1 Git commands.....................................................................................................................21
1.7.2 Start making changes..........................................................................................................25
1.7.3 Conflicts...............................................................................................................................27
1.7.4 Importance of version control ............................................................................................28
1 Module 1: Embedded Software Essentials
1.1 Introduction to Embedded System
1.1.1 Embedded Systems Software Design
Embedded software engineers need to have expertise and understanding hardware concepts, knowing
how to correctly write and design low-level software, and knowing how to use tools to interact and
evaluate their platform.
1.1.2 Software requirements
There are some software requirements for the local environment that you'll need to install and set up
before you begin any development.
Depending on the development kit, you'll need to install the vendor provided Integrated Development
Environment, or IDE.
You will need to install a Serial Terminal program that we can interact with later in the course. I suggest
Real Term for this.
The next thing you will need is to get access to a Linux development environment. For this, I suggest
using Virtual Box with an Ubuntu Linux image.
Within Linux, you'll need to install some specific packages for our course tool set. These include git, a
host version of GCC, and the Embedded GCC Cross-Compiler. In addition, you'll need a method for
editing files in Linux. Here you can choose whatever file editor you'd like.
1.1.3 What Embedded System is?
An embedded system is a computerized system that is purpose built for its application.
1.1.4 Limited Resources
Processing, memory, and peripherals.

1.1.5 The development platform components
Include a host machine, a development environment to write and test code in. A compiler toolchain to
generate designs, development kits to integrate with, and version control to track software history.
1.1.6 Microcontroller
Microprocessors and microcontroller are not the same. A microcontroller is a microprocessor with
added functionality such as memory and peripheral hardware. The processor of the microcontroller is
called the CPU or the Central Processing Unit. This is a piece of hardware that runs our software by
fetching and executing assembling instructions for memory. This instructions perform math and logic
operations as well as coordinating data movement.
1.1.6.1 Microcontroller Components

1.1.6.1.1 CPU:
CPU has many sub components with many responsibilities. Many registers general purpose and special
purpose. Store operations data and systems state. An Arithmetic Logic Unit (ALU), performs the
fundamental low level assembly operations, an Interrupt Controller coordinates a synchronize events
requests of the processor.
Lastly a Debug interface is used to help troubleshoot and store programs.
1.1.6.1.2 Bus controller:
The CPU and its subsystems interact with other microcontroller resources you want to more buses. A
bus controller aids the processor in this data transmission between memory and peripherals.
1.1.6.1.3 Memory:
Memory holds data that we operate on as well as the program that we're executing. This data is stored
in a combination of flash and Random Access Memory or RAM.
1.1.6.1.4 Clocks:
A clock system provides synchronization across all these components. And to wrap up on trip power
management hardware is used for regulation and monitoring.
1.1.6.1.5 Peripherals:
A variety of peripherals hardware maybe included in a micro controller. Some tip of peripheral
functionality you will see include communication, analog signal processing Input and output, timing and
processor's support.
1.2 Embedded Software Engineering
Software engineers often want to jump straight into coding before putting time into code design and
architecture. Good software design needs to understand what the purpose and required operations

specifications that a project needs. It's good to start by breaking a software concept down into flow
diagrams or software blocks.
1.2.1 Flow Diagram:
A flow diagram can depict, how a particular piece of software or algorithm should behave. Often it
contains a same functional software contracts, such as conditional decisions and high level function
calls.
1.2.2 Software Block Diagram:
Software Block Diagram did not differ greatly from a hardware block diagram, you often see for circuit
boards and micro controllers. Instead, they depict how different blocks of code communicate and
connect to one another. That being said, a Software Block Diagram can also depict a software system in
layers.
Writing code to direct the interface of the hardware is referred to as bare-metal firmware.
A firmware engineer requires deep knowledge of the hardware, not only for configuration of the bare-
metal but also for hardware timing and limitations related to their software design.
A software engineer's role will be to try and segment the hardware interface into something referred to
as a HAL or Hardware Abstraction Layer.

By design this interface works as a module component but they well defined interface. It allow software
above the HAL layers become platform independent or agnostic to the specific hardware
implementation, a concern layers, portable across platforms.
1.2.2.1 Component Design Method:
A common software block design method is called component design. This is where we define small
functional software blocks that have certain tasks. We define the interface mechanism and the specs
that each modules needs to adhere to. By doing this, you can build modulize software that is reusable
across different systems, architectures and platforms. This will allow software developers to easily
migrate certain software solutions without significant system changes. It is very important you
understand that with this design paradigm, good interface definitions are a key for successful
implementation. Example components can be seen in the layers where a wireless control embedded
system is built. There's is a hardware firmware layer that controls peripheral hardware. There's an
extracted interface to this layer that is hardware independent. Those are interfaces with some high level
communication libraries, above that is a control library that utilizes hardware interfaces.

1.2.3 Five main development tools:
There are five main development tools that allows software engineers to get started on development
and testing of their applications. These are first simulators, software that imitates or intended to
hardware's behavior without the actual hardware. Emulators, the hardboard platform that imitates the
operation of your intended system. Compilers, it's the software that allows developers to pre-
executable code for their intended architecture. Installers, a software-hardware combination that
allows compiled executable programs to be installed onto a platform. And debuggers, a hardware-
software solution that allows programmers to test and validate their executable programs. These tools
are important because developing hardware takes time and it's expensive
These five tools make the job of the embedded software engineer easier. How? Simulators and
emulators will allow validation of design to occur before the arrival of hardware. Compilers, Installers,
and debuggers will provide a quick development of features for your embedded target. And an easy way
to fix off our bugs. Having the ability to do this in software gives the team more flexibility and likely a
cheaper product development cost. Prototyping software fast is important, but not at the cost of
quality.
1.2.4 The principles of high quality software
These principles are beliefs that ever software engineer should keep in mind as they write code, to
achieve maximum amount of quality. This lest includes but is limited to writing code that is
maintainable, testable, portable, robust, efficient and consistent. By keeping this tenants in mind
with software, you can ultimately write better code, speed up development by using all code and
produced system bug free software.
1.2.5 Embedded software languages:
There are many embedded software languages use in the industry such as C, C++, Java and Ada. But C-
Programming is the most widely used language for embedded software design. C-Programming has

benefits for both low level hardware interactions and high level software language features. This
provides portability across different embedded platforms. Software engineers choose to use this over
assembly language for many reasons. C is high level enough that you do not need to know every detail
about the very specific assembly level architectures. Assembly often still used together with C for a small
number of embedded features, but very few regular occurrences. Regardless, all higher level link images
need to be converted into the architecture specific language before installation can occur. Typical
embedded engineers actually write a form of C called Embedded C.
1.2.5.1 Embedded C:
Embedded C differs from C because it puts a focus on the following features. Efficient memory
management, timing centric operations, direct hardware/IO control, code size constraints,
and optimized execution.
In general, you can think of Embedded C as optimum features in minimum space and time.
______________________________________________________________________________
1.3 Software Configuration Management
Software configuration management, or SCM for short, is a process that is used by software teams to
develop software projects. This process contains a diverse set of goals and guidelines that dictate the
software processes for version control, development process, environmental information, software
build and release, software review, testing, support, defect tracking, and task management. There are
often more topics that were not listed, and sometimes these topics are even broken down into further
granularity.

Version Control is one of the most important tools a software engineer should learn. This allows all
changes of a software project to be tracked indefinitely. Version control is usually combined with
software review as a way to prevent poorly designed software contributions into a project. Software
teams will use these two guidelines, along with specific coding standards. The development
environment will be where an engineer can actually develop code by providing many integrations with
things like testing, building and installation.

Your host machine will contain your build system in addition to many components of our SCM such as
our version control system, the compiler tool sets, the developer environment and the installer.
Eventually, we will take your pre-built software and start to install it into the microcontroller. You can
similarly test your code on your host environment to help your validation of code before you go on
target. However, it is important that you actually test your code on your intended embedded system.
1.3.1 Legacy systems
Older Systems that may or may not be supported anymore.
There will be many reasons why systems becomes legacy, whether a software or hardware is outdated,
loss of compatibility between components on the system, parts not available any more or company has
moved in off the roadmap and are potentially not supporting that product anymore.
How well you define or remember your project SCM practices will make the resurrection of legacy
systems, the development of new systems even move on to new teams more successful throughout
your career. Using your legacy systems as lessons learned and also re-use will speed up your
development of future products.

1.3.2 Task management and defect tracking
Where each software task has requirements for you to complete and record. Breaking down a software
design into manageable modules works hand in hand with tracking the task for a software project.
1.4 C Standardization and Team Coding Standards
Software languages will evolve over time just like software applications do. New versions with new
features will be released, and software teams will need to make important decisions. What language
should they use? What version should they support? What guidelines should be defined on the use of
this language? Software teams will need to have a complete understanding of these questions if they
are to develop a project that can be maintained and expanded upon for an extended amount of time.
One important characteristic of higher level languages is that the language is standardized and portable
across platforms, ensuring that C programming means the same thing from one project to the next.
Standards provide specific syntax and features what each version of the language supports.
Organizations like the International Electrical and Electronics Engineers IEEE, the International
Organization for Standardization, ISO, and the American National Standards Institute, ANSI, are three
groups that are involved with the process of standardizing various technical ideas including software.
Without organizations like these, creating portable projects would require much more engineering
overhead.
1.4.1 C-Programming Standards
It wasn't until the late 1970s that the first unofficial standard of C programming was created by Ken
Thompson and Dennis Richie. This classic version of C was referred to as K&R C, This version of C was the
standard for C programming for about 15 years.
In 1989, ANSI-C standard was introduced, and in 1990, ISO adopted the standard officially. These are
referred to as C89 or C90. C99 came out about a decade later with some more features. And C11 is the
most recent C standardization, and it has introduced many features specifically related to multi-
threading.
1.4.2 Coding Standard
A coding standards is simply a list of software guidelines a project will need to be written to. These
standards can be a mixture of requirements. There could be special format and documentation of the
code needed. You many need to program the flow of routines in a certain way. How you name

functions, files, and variables may need to fit a certain scheme. You may even have limits on the types of
features, a developer can use on a platform.
Software team usually enforce a coding standard that must be adhered to for anyone contributing for
the code base.
So keeping the code base consistent helps reduce the possibility of syntax bugs or bad practices. Plus
you'll get added benefit of enhanced readability. And ensure security, portability, reliability and safety of
software.
1.4.3 MISRA (Motor Industry Software Reliability Association)
The Motor Industry Software Reliability Association introduced an industry standard coding guideline
called MISRA C, which was specifically aimed at embedded architectures. Software teams could
implement these guidelines for their own projects or instead develop their own internal standard.
1.5 Development Environments Overview
The primary goal of the development environment would be to allow engineers to write, compile, install
and debug a program.
In order to show all of the features that the development environment offers. We'll be using two
different desktop environments. A command line in a Linux environment and a vendor's Integrated
Development Environment.
1.5.1 Command line
Building software project using command line is the standard amongst software engineers. The
command line interface gives you a powerful level of control of applications at the expense of user
interface. You'll provide complex commands to the computer via text input. The command line is
typically a power user interface. Command lines are not regularly used because they are not intuitive,
but they exist on many computers.
In Linux, we'll use different programs to perform these four software operations, starting with your
editor, you are free to use whatever editor to develop your code in. The simplest editor you can use
would be a text editor such as Notepad++, Vim or Sublime Text. Some file editors have some options for
integrating compiler debugger plugins that would make them look more like an IDE that is not vendor
specific. For compilation, you will use GNU's toolset to generate our software executable files.
Installation and debugging will be an architecture dependent thing. However, installation could be as
simple as copying our executable or invoking an installer program. Debugging will depend on the target,
Host debugging can utilize a command line tool GDB, and the GNU project debugger. On target
debugging can be done through a network debugger or connected hardware debugger. These two
require some type of physical control of our microcontroller.
1.5.2 Integrated development environment
IDEs encapsulate all of the functionality that we get from the command line. But they provide a much
more interactive use interface. The IDE will hide all of the details of how the compiler, installer and
debugger application are being invoked from the developer.
This interface is usually less ideal for software engineers because the tradeoff for a good UI might
restrict a developer's capabilities.

With the IDE we will perform all four steps of our software design tool set in this one environment.
1.6 Development Kits and Documentation
Knowing how to pick a particular chip is difficult because there are particular factors you need to
investigate before committing a product to a particular chip choice. Inside the IC, there's also a chance
that different parts of silicon were built by different people.
Microcontrollers have many features that you need to know about before making a selection, especially
because there will be software implications. Some important features include the word size, the
number of registers, flash and RAM sizes, branch prediction support, instruction and data
cache support, floating point arithmetic support, or DMA support.
Fortunately, manufacturers help with this process by providing resources to analyze their products.
There are many documents that describe how to pick out a platform or evaluate a particular chip. We
start with discussing the Selector Guide.
1.6.1 The Selector Guide
If you find some interesting parts from the selector guide, you can obtain some more information using
the product brief.

1.6.2 The product brief
This gives a concise overview for quick evaluation of a platform for design, but more details than what
you will see in the selector guide. This is much more marketed, and is far less dense than strict product
specifications.
Once you have slimmed down your selections to a subset of models, you can start getting into much
more detailed documentation sources like the datasheet.
1.6.3 Datasheet
This document gives technical specifications on a chip or a family of chips with a breakdown of all the
differences between each version or part number within the family.
Pin counts as well as operation specifications are provided with diagrams, tables and plots. These
operation specifications can include many things. Electrical characteristics such as voltage and current
operating ratings, where we get information on power specs of various conditions and operating modes.
Timing characteristics are provided for our operation of the microcontroller. You will find info on the
limit of the processor's clock frequencies. There are timing diagrams that show expected time delays
before certain digital signals are asserted.
The datasheet even includes some extra data on how environmental effects, such as temperature, can
affect the device or the operation characteristics.
Lastly, you will also find physical design constraints, such as a CAD drawing with dimensions for the
physical package and footprints of the chip.
The datasheet does not typically provide information on configuration. For that, we need to look at the
Family Technical Reference Manual.

1.6.4 Family Technical Reference Manual
This manual describes information on general platform components and configuration. You may then
have a sub-family reference manual which covers particular settings of a specific device. These are
manuals that you need to look up to know how you go about configuring a chip using Bare-Metal
Firmware
Sometimes the Family Technical Manuals are missing information or issues are found with the chip after
the release of the product. This is called the Chip Errata.
1.6.5 Chip Errata
This is a document that contains additional and corrective information for our particular device set. It
will list problems with the description of the configuration or the hardware's operation. They usually
provide a workaround in the errata sheet. It is important that if something is operating unexpectedly
with your chips that you consult the errata.

1.6.6 Development kits
Many businesses just create development kits and module boards so that prototyping can be done
easily, speeding up the time it takes chip manufacturers to get their products in customer hands for
evaluation.
Here we have two example development kits. The first is a microcontroller development kit called the
Freedom FRDM-KL25Z
A second example is the wireless module featuring the Nordic nRF24L01 chip.

1.7 Version Control Systems
Version control will be used to track our software changes.
Version control systems, or VCS, or alternatively revision control systems, RCS, is a software package
that allows users to track changes in a project over time.
The VCS gets installed on the host machine where you develop your code.

This collection of software project files and version control files is call the repository or a repo.
Each historical change that is tracked is called a commit. A commit is a bundle of information including
textual software changes in commit tracking info.

All changes you make to your repository stay local until you push your changes out to the remote
repositories.

Oftentimes, you keep a central, or master repository where all users push their changes for
collaboration. This remote repository is often referred to as the origin in your local Git workspace.
Also, you may track any other coworker's repository by mapping them as a remote in your local
repository with a unique name. That way, you can share content directly with these individuals and be
immediately updated when they make changes to their own local repositories.

Access to the repository is dictated by the owners. Companies will store a private repositories on
internal servers to protect their intellectual property. While open source projects will make their code
available on repository store sites, like GitHub, BitBucket, or SourceForge.
1.7.1 Git commands
Git task Notes Git commands
Tell Git
who you
are
Configure the
author name and
email address to
be used with
your commits.
Note that
Git strips some
characters (for
example trailing
periods)
from user.name.
git config --global user.name "Sam Smith"
git config --global user.email sam@example.com

Create a
new local
repository
git init
Check out
a
repository
Create a working
copy of a local
repository:
git clone /path/to/repository
For a remote
server, use:
git clone username@host:/path/to/repository
Add files Add one or more
files to staging
(index):
git add <filename>
git add *
Commit Commit changes
to head (but not
yet to the remote
repository):
git commit -m "Commit message"
Commit any files
you've added
with git add,
and also commit
any files you've
changed since
then:
git commit -a
Push Send changes to
the master
branch of your
remote
repository:
git push origin master
Status List the files
you've changed
and those you
still need to add
or commit:
git status
Connect
to a
If you haven't
connected your
git remote add origin <server>

remote
repository
local repository
to a remote
server, add the
server to be able
to push to it:
List all currently
configured
remote
repositories:
git remote -v
Branches Create a new
branch and
switch to it:
git checkout -b <branchname>
Switch from one
branch to
another:
git checkout <branchname>
List all the
branches in your
repo, and also
tell you what
branch you're
currently in:
git branch
Delete the
feature branch:
git branch -d <branchname>
Push the branch
to your remote
repository, so
others can use it:
git push origin <branchname>
Push all branches
to your remote
repository:
git push --all origin
Delete a branch
on your remote
repository:
git push origin :<branchname>

Update
from the
remote
repository
Fetch and merge
changes on the
remote server to
your working
directory:
git pull
To merge a
different branch
into your active
branch:
git merge <branchname>
View all the
merge conflicts:
View the conflicts
against the base
file:
Preview changes,
before merging:
git diff
git diff --base <filename>
git diff <sourcebranch> <targetbranch>
After you have
manually
resolved any
conflicts, you
mark the
changed file:
git add <filename>
Tags You can use
tagging to mark
a significant
changeset, such
as a release:
git tag 1.0.0 <commitID
>
CommitId is the
leading
characters of the
changeset ID, up
to 10, but must
be unique. Get
the ID using:
git log

Push all tags to
remote
repository:
git push --tags origin
Undo
local
changes
If you mess up,
you can replace
the changes in
your working
tree with the last
content in head:
Changes already
added to the
index, as well as
new files, will be
kept.
git checkout -- <filename>
Instead, to drop
all your local
changes and
commits, fetch
the latest history
from the server
and point your
local master
branch at it, do
this:
git fetch origin
git reset --hard origin/master
Search Search the
working directory
for foo():
git grep "foo()"
1.7.2 Start making changes
When you are ready to start making changes, you can follow a simple workflow. You start by creating a
development branch.
1.7.2.1 Development branch.
A branch is just a way to organize your changes without affecting the code base and indicates that
you're going to diverge from the main line of development. You can name your branch whatever you
want and you can maintain many different branches, tracking different features and bug fixes within the
same repository without them affecting one another.
1.7.2.2 Make changes
Once you create a branch, you can begin to make changes to your files with your favorite file editor.

1.7.2.3 Stage file for commit
Once you make a change, you stage the file to be committed. When you're confident with the change,
you commit the change and the repository logs and you commit.
1.7.2.4 Commit the change
When you're confident with the change, you commit the change and the repository logs and you
commit.
1.7.2.5 Push Change to Remote
Once a change is being committed, you can push that change using the git push command to a master
repository rather users to sees news. They can collect and pull down your changes to their local repos by
using the git fetch or the git pull commands.

1.7.3 Conflicts
As more contributors add to a single software repo, the need for creating a team workflows developed.
This is because developers will eventually make changes that conflict with one another as similar files or
lines of code need to be edited. Conflict resolution is unavoidable as collaboration grows. Resolving
conflicts is done by analyzing the differences between software sets and creating a new commit that
represents the merge development of the two developers. Somewhat of a manual process is used to
merge conflicting files into a single file. Tools like git diff allow you to investigate the changes in files
around focused areas between commits. The commands that help trigger and start conflict resolution
are performed by using the git merge program or the git rebase command.

1.7.4 Importance of version control

Module 1 embedded software essentials

Recommended

Recommended

More Related Content

Similar to Module 1 embedded software essentials

Similar to Module 1 embedded software essentials (20)

Recently uploaded

Recently uploaded (20)

Module 1 embedded software essentials