Basic Software Techniques for

Embedded Applications and

Parallel Input and Output
CPE112: Embedded Systems
Software Programming and Implementation Guidelines

1. syntax-oriented
▪ how the code looks and is written
2. rules that programmers must follow
▪ to keep the code “cleaner”

❑ The ways that software is written and how it is formatted can bring about
heated arguments between developers.
Factors to consider in writing software
1. Project size
▪ are arguments around project structure, use of global variables, and other
factors
2. Programmers’ Experience And Background
▪ implementation guidelines and standards that that group is comfortable
doing and provide benefit to the rest of the team
▪ Don’t fall into the trap of believing “that is the way it has always been done,
keep doing it”
▪ assessment of the way programming and implementation is being done is
healthy
Factors to consider in writing software (Cont’d)

3. Maintainability and Project length

▪ useful comments in code is always good for reviewers and even to jog your
own memory
4. safety-critical code development
5. software that is being sold as software for others to use in their
product
6. industry regulations for your product or market segment.
Principles of High-quality programming
1. Readability
2. Maintainability
3. Testability
4. Portability
5. Reusability
Readability
• software is read and understood
• somewhat objective
• helps in reviewing and maintaining it over the course of its life
• Simplicity in logic, conditional statements, and the structure of the
code all help with readability.
Readability
❑ The following is an example of a proper “C” code segment, ❑ With a little better readability, the same conditional can
that isn’t entirely readable: be written as:

// Check for stuff to proceed // Check for secure testing to be running, or if vehicle is stopped
if((!((Engine_Speed! 5 0)jj(Vehicle_Speed! 5 0))) || SecureTest! // along with the engine not running. Then we can execute
5 FALSE ){ ,<ABC>
// ABC... if (( Secure_Test 5 5 TRUE ) || \
} (( Vehicle_Speed 5 5 0 ) && ( Engine_Speed 5 5 0 )))
{
// ABC...
}
Maintainability
❑ measures how easily software can be maintained
❑ relates to the size, consistency, structure, and complexity of the codebase
▪ ensuring maintainable source code relies on a number of factors, such as testability
and understandability
❑ use descriptive comments in the code for the “intent” of what is being
done
❑ For example, a comment of “Reset timer because if we are here we have
received a properly formatted, CRC-checked, ping request message” is
much better than “Set timer to 10 seconds”.
Testability
❑ measures how well the software supports testing efforts
❑ relies on how well it can control, observe, isolate, and automate testing,
among other factors
❑ can be measured based on how many test cases you need to find
potential faults in the system
❑ Size and complexity of the software can impact testability.
❑ Applying methods at the code level — such as cyclomatic complexity —
can help you improve the testability of the component.
Testability
❑ For unit testing, or debugging of code
▪ test each executable line or test each path the software could take
❑ Combining executable lines within conditional statements is not a good
idea.
❑ Consider the following code segment:
if ( GetEngineSpeed() > 700 )
{
// Execute All Speed Governor code
}
Testability
❑ high-level source code debugging
▪ it would not be immediately clear what the engine speed
❑ The tester could analyze the particular register being used for the return value, but it
certainly is not readily apparent.
❑ Re-writing the code to use a local variable allows the variable to be placed into a watch
window or other source analysis window. The code could be re-written as follows:

current_engine_speed 5 GetEngineSpeed();
if ( current_engine_speed . 700 )
{
// Execute All Speed Governor code
}
Things to consider in writing Embedded
Systems Software/Program
❑ Resources ❑ Hardware features
▪ every line of code and module that is ▪ software is split between the
written is scrutinized for the hardware pieces of the embedded
processing time it takes to execute as system that can execute them more
well as the amount of other resources efficiently as opposed to separating
(such as memory) that is being used. software by a software-only
▪ It becomes more difficult writing a architecture.
tight embedded system using ▪ Interrupts, DMAs, and hardware
dynamic allocation languages such as coprocessors are key components in
C++ and Java, versus programming software design
languages like C and assembly.
Things to consider in writing Embedded
Systems Software/Program
❑ Performance
▪ an embedded programmer has a keen sense of what the hardware can and
cannot do.
▪ For processors that do not have floating-point units, mathematical equations
and calculations are done using fixed-point math.
▪ The programmer also focuses on performing calculations that are native to
the atomic size of the processor, so they shy away from doing 32-bit
calculations on a 16-bit processor, for instance
Starting the embedded software project
• Hardware platform input
• Project files/organization
• Team programming guidelines
• Syntax standard
• Safety requirements in source code
• Variable structure
• Data types
• Definitions
Hardware platform input
❑ Items like hardware interrupt request lines, and what they are tied
to, to play a key role in the organization and the performance of the
embedded software.
❑ other resource input such as memory size, on-chip vs. off-chip
resources, processor being used, and other hardware I/O interfaces
are critical to embedded development
❑ An interface like JTAG may be perfect for hardware checking, but
may not have all of the functionality that is available for a software
programmer
Project files/organization
• Source files written locally
• Source files from company
libraries
• Libraries from third parties
• Libraries from compiler/linker
toolset
Team Programming Guidelines
❑ How a team agrees to program ❑ Guidelines could include a variety
the system and the criteria they of rules or recommendations.
will use for evaluating other ▪ measurable, the more successful they
programmers’ source code is will be.
important to decide up front.
❑ The criteria for how a
programmer can successfully
pass a code review should be
understood up front, so time isn’t
wasted re-writing and re-unit-
testing code.
Team Programming Guidelines
❑ For example, if there is a guideline for the programmer that “the
code is not complex” as one of the criteria, it could be largely
subjective to a group of programmers.
▪ use a cyclomatic complexity measurement
▪ software is run through a tool, and it produces a complexity number for the
module
▪ Higher values = more complex code
▪ 1 = simplest complexity (no if or for condition, single entry and exit point)
Software Guidelines Checklist
❑ Conformance to syntax standard
❑ Cyclomatic complexity calculation
❑ Number of source lines per function / per file
❑ Number of comments
❑ Ratio of number of source lines per number of comments
❑ Run through code formatter
❑ Comment and design document understandability / matches code
❑ Code under CM control / linked to “change request”
❑ No compiler warnings
Software Guidelines Checklist
❑ Rule exceptions properly documented (if warnings ignored or doesn’t
match standard)
❑ #pragma directives documented clearly in source code
❑ Non-constant pointers to functions are not present
❑ All members of union or struct are fully specified
❑ Data representation (scale, bits, bit assignments) clearly documented
❑ Data defined and initialized before being used
❑ Loop bounds and terminations are correct
❑ Mathematical operations correct (no divide-by-zero, overflows)
❑ No deadlocks, priority inversions, re-entrant faults
Syntax Standard
❑ way code is spaced, capitalized, and formatted when written into
source code
❑ getting the developers to agree on a given standard and sticking to
it throughout.
Syntax Standard
1. Code white space
2. Tabs in source files
3. Alignment within source
Syntax Standard: Code white space
❑ add white space to increase the printf( “%02u”, i*2 );
readability of the code }
int i; int i;
for(i 5 0;i,20;i11) for ( i 5 0; i , 20; i11 )
{ {
printf(“%02u”,i*2); printf( “%02u”, i * 2 );
} }
int i;
for ( i 5 0; i,20; i11 )
Syntax Standard: Tabs in source files
❑ tab characters should not be ❑ Depending on the spacing that
used in source files when is used for other things, like
writing code the “for” loop spacing above,
❑ interpreted differently by the amount of indent space
source editing tools, file may align better with what is
viewers, or when it is printed. chosen.
❑ not readily visible when editing
Syntax Standard: Alignment within source
❑ How things are aligned in source code makes an impact on
readability as well.

int incubator 5 RED_MAX; /* Setup for Red Zone */

char marker 5 ‘\0’; /* Marker code for zone */

int incubator 5 RED_MAX /* Setup for Red Zone */

char marker 5 ‘\0’; /* Marker code for zone */
How Safe is Our Real-Time Software?
Safety Requirements in Source Code
❑ Failure Modes and Effects Analysis (FMEA)
▪ a systematic, proactive method for evaluating a process to identify where and
how it might fail and to assess the relative impact of different failures
❑ Special care and consideration should be made to mark these
sections differently, or even have comments that refer directly to
the safety case or documentation that the code adheres to.
▪ Using all capitals such as “SAFETY-CRITICAL CODE SECTION START” in a
comment section certainly alerts programmers
Safety Requirements in Source Code
❑ Development standards such as “MISRA C” (Motor Industry Software Reliability
Association) and “MISRA C++” can also help facilitate writing code that operates
in a safe manner.
Checklist Items for Safety-critical Code Development

❑ Adherence and checking to a standard, such as MISRA C or C++

❑ Safety sections clearly marked to standard
❑ Data that is safety-critical is marked that way in the variable name
❑ All safety-critical variables are initialized to the least permissive
state
❑ Any safety-critical data is clearly marked as stale and/or deleted
after use
❑ Comparisons between safety-critical data are handled correctly
Checklist Items for Safety-critical Code Development

❑ All paths are covered when variables are used for path decision-making
❑ Checks are in place to make sure safety-critical code is executed on-time
❑ Periodic flash and RAM checks are done to check hardware correctness
❑ Safety-critical data is protected by regular CRC or data integrity checks
❑ “Voting” mechanisms between software and processors is done correctly
❑ Safety dependencies on functions (like watchdog timer) are checked
periodically for correct operation
Variable Structure
❑ Variable declarations
▪ global, local, file-scope and function-scope variables
❑ Data types
▪ embedded system portable to other processors, and to keep resources in
check, type definitions could be used for the various data types.
Input/Output Devices
Input/Output
❑ Peripheral devices
❑ Pieces of equipment that exchange data with a computer
❑ Examples: switches, light-emitting diode, printer, keyboards, and
disk drives
Interface (Peripheral) chip
❑ Synchronize data transfer between CPU and I/O devices
❑ Consists of control registers, status registers, data direction latches,
and control circuitry
❑ Has pins connected to the CPU and I/O ports pins
❑ Each interface chip has a chip enable signal input/s, When asserted,
allow the interface chip to react to the data transfer request.
❑ Data transfer between an I/O devices and the CPU can be
proceeded bit-by-bit or in multiple bits (parallel).
Interface (Peripheral) chip
❑ Address decoder makes sure that each time one and only one
peripheral device responds to the CPU’s I?O request.
from to
Address
input output
D ecoder
I/O pins device
device

𝐶𝐸 𝐶𝐸
Interface Interface
chip 1 chip 1

Microprocessor

Data Bus
I/O Addressing
❑ The processor needs to access the registers of the interface chip to perform the
I/O operation.
❑ An address is needed to select the register inside the interface chip and
instructions need to be executed to carry out the appropriate operations.
❑ Two issues arise here:
1. Address space sharing
2. Instruction set and addressing modes sharing
I/O Synchronization

handshake or
Control signals strobe signal
I/O device
Microprocessor Interface chip electronics
ഥ
(such as R/𝑊or
interrupt)
Data Bus

Data Bus Data Bus

I/O Synchronization
- For input, the CPU needs to make sure it reads when the data is
valid and reads only once.
- For output, the CPU needs to make sure that the output device is
ready to accept new data.
- There are two aspects in the I/O synchronization: the synchronization
between the CPU and interface chip and the synchronization
between the interface chip and the I/O device.
Synchronization between the CPU and Interface Chip

1. Polling method
▪ Use a flag bit to indicate the readiness of I/O operation.

2. Interrupt-driven method
▪ Use the interrupt signal to inform the CPU that new data is available or
output device is ready for more data.

• None of the PIC18 I/O ports support either method directly.

Synchronizing the Interface Chip with I/O Devices
1. Brute-force/ No method
▪ Data timing is unimportant
▪ Input: The interface returns the current value of the input pins.
▪ Output: The interface drives the data written by the CPU directly on output pins.

2. Strobe method
▪ A strobe signal is used to synchronize data transfer.
▪ Input: The input device places data on input pins, wait until data is stable, and then asserts the strobe
signal to inform the interface chip to latch the data.
▪ Output: The interface chip drives data to be output on the output pins, wait until data is stable, and then
asserts the strobe signal to inform the output device to latch the data.
▪ PIC18 does not support this method.
Synchronizing the Interface Chip with I/O Devices
3. Handshake method
▪ Two handshake signals are used to synchronize the data transfer between the interface chip
and I/O device. H1 is driven by interface chip and H2 is driven by I/O device.
▪ There are two versions of handshaking: pulse mode and interlock mode.
▪ Handshaking signals transactions for input and output are shown in Figure 7.3 and 7.4,
respectively.
Address Bus
❑ normally used to read or write to memory, most often RAM chips. Most
modern microprocessors use the address bus for more than just reading and
writing to memory however.
❑ I/O port addressing
▪ Toggling a special pin, the CPU can switch from using the address bus for accessing RAM, to using the
address bus to talk to other semi-intelligent chips.
▪ occurs from devices like serial ports, parallel ports, floppy, hard drive and other controllers
▪ Once the CPU has placed the proper address on the address bus and it asserts the special I/O pin, all
RAM chips are temporarily disabled and the external I/O chips are read or written from instead.
▪ The bytes of data are actually transferred on a second set of pins called the data bus.
Data Bus
❑ a series of pins on the processor that are used to get data into, or
out of, the processor chip itself
❑ All memory and I/O devices are connected to the data bus.
❑ Only one chip can actually be connected to the data bus at any
given moment.
❑ Data bus may be 4, 8, 16, 32 or perhaps 64-bits wide
❑ Wider data bus allows the processor to read and write more bits of data in a single
operation and is used with PCI-based cards on PC-compatibles to achieve faster I/O
operations for certain devices.
Interrupt Requests
❑ the external devices use another pin when they need the attention
of the processor, Interrupt Request Line (IRQ) Line
❑ The interrupt handler must be small and efficiently designed, since
in some cases it could be invoked hundreds or maybe even
thousands of times a second.
❑ Interrupt handler performs the minimum amount of work necessary
to service the device, and then exits.
Interrupt Requests
❑ Two different types of interrupt lines:
1. Maskable interrupt
▪ interrupts can be selectively enabled or disabled by the software
2. Non-maskable interrupt
▪ software can never disable this kind of interrupt
▪ often used to perform the DRAM refresh on memory chips, which MUST occur at regular
intervals in order to keep memory contents alive.
I/O Schemes
1. Isolated I/O scheme
▪ Microprocessor has dedicated instructions for I/O operations
▪ Microprocessor has a separate address space for I/O devices
2. Memory Mapped I/O
▪ Another commonly used technique for the processor to communicate with
external devices
▪ processor just accesses a memory address directly.
▪ external device can have a small amount of RAM or ROM that the processor
just reads or writes as needed.
Direct Memory Access
❑ one technique that has been used for years to speed transfer of data from main
memory to an external device's memory
❑ The processor on the external device executes DMA transfers, without any
assistance from the main processor.
❑ While the DMA transfer is in progress, the main processor is free to tend to
other tasks, but should not attempt to modify the information in the buffer
being transferred, until the transfer is complete.
❑ The external processor will take over the address and data lines periodically and
execute the DMA transfer.
Direct Memory Access
❑ Once the transfer is complete, the external device usually notifies
the main processor of this by raising an interrupt request.
❑ Advantages
1. main processor does not have to transfer data into one of its register, then save that to a
memory address for each and every byte of data
2. CPU is free to work on other tasks while DMA transfer is in progress. This leads to an
apparently overall increase in speed.
Thank you for listening.
References
• What Is Code Quality? And How to Improve Code
Quality.https://www.perforce.com/blog/sca/what-code-quality-and-
how-improve-code-quality
• FMEA
http://www.ihi.org/resources/Pages/Tools/FailureModesandEffectsAn
alysisTool.aspx#:~:text=Failure%20Modes%20and%20Effects%20Anal
ysis%20(FMEA)%20is%20a%20systematic%2C,most%20in%20need%2
0of%20change.
References
• Alberto Sangiovanni-Vincentelli.
https://inst.eecs.berkeley.edu/~ee249/fa07/introductionee249_07.p
df
• Han-Way Huang. Thomson Delmar Learning.
https://owd.tcnj.edu/~hernande/ELC343/Chapter_07.pdf