UNIT 3

Industry Standards for Embedded Systems

Comprehensive Exam Notes
MIT Academy of Engineering | Embedded Edge AI

SYLLABUS COVERAGE
Topics: Embedded C | ANSI-C/ISO C Standards | CMSIS | MISRA | AUTOSAR
CO 3: Evaluate their designs as per industry standards [L5]
Case Study: MISRA C: 2023 — Automate MISRA Coding Standards Compliance
1. Why Do We Need Programming Standards?
Computers understand only machine language (binary: 0s and 1s). Embedded systems add more
constraints — limited memory, real-time deadlines, safety-critical requirements. Standards exist to
bridge human thinking and machine execution reliably.

Without Standards With Standards

Code is unreadable, hard to Consistent style, easy to review
maintain
Bugs are hidden in ambiguous Ambiguities are removed or flagged
constructs
Porting to new hardware is Portable, reusable modules
painful
Testing is ad-hoc and Structured unit + integration + stress tests
incomplete
Safety violations go Compliance ensures functional safety
undetected

2. Embedded C — Language Basics

2.1 What Is Embedded C?

Embedded C is an extension of standard C designed for writing firmware that runs on
microcontrollers and embedded processors. It retains almost all standard C syntax but adds
hardware-specific features.
• sbit: and sfr for addressing Special Function Registers (SFRs) in memory.
• Allows direct interaction with hardware peripherals (GPIO, SPI, I2C, UART, PWM).
• Compilers are hardware-specific (e.g., Keil C51 for 8051, ARM GCC for Cortex-M).

2.2 C vs Embedded C — Comparison Table

Parameter Standard C Embedded C
Definition General-purpose, runs on Extension of C for
desktop OS embedded/firmware development
Hardware Dependency Hardware-independent (same Tied to specific MCU; register
OS) names, I/O differ per chip
Resources Abundant RAM, ROM, OS Extremely limited RAM, ROM, no
services traditional OS
OS Dependency Runs on top of OS (Windows, Bare metal or minimal RTOS; no
Linux) traditional OS needed
Portability Highly portable across platforms Portable with modifications;
hardware-specific sections
Special Keywords None beyond standard sbit, sfr, interrupt, using, etc.
Application Desktop, server, general Microcontrollers, IoT, automotive
software ECUs, medical devices
 EXAM TIP
Exam Tip: The key difference examiners ask — Embedded C is hardware-dependent.
The same .hex file generated by an embedded compiler ONLY runs on that specific MCU family.

2.3 Advantages and Disadvantages of Embedded C

Advantages
• Easier to write than assembly language — less time consuming
• Code is readable, maintainable, and easier to debug
• Standard library functions can be reused across projects
• Portable to other microcontrollers with minimal modifications
• Faster development cycle compared to pure assembly

Disadvantages
• Cannot perform true multitasking (one task at a time without RTOS)
• Not scalable — changing application may require hardware change
• Only supports the specific hardware it was compiled for
• Limited by constrained RAM, which affects compatibility

2.4 8051 LED Blinker — Three-Level Example

This classic example shows how the same logic is expressed at three levels:

/* EMBEDDED C (Keil C51) */

#include <reg51.h>
void delay(void) { /* delay loop */ }
void main(void) {
while(1) { P1_0 = 1; delay(); P1_0 = 0; delay(); }
}

/* ASSEMBLY (8051 ASM51) */

MAIN: SETB P1.0 ; Set pin high
ACALL DELAY
CLR P1.0 ; Set pin low
ACALL DELAY
SJMP MAIN

/* MACHINE CODE (Hex) */

0000H: D2 90 ; SETB P1.0 (D2=opcode, 90=bit addr)
0002H: 11 4D ; ACALL DELAY
0004H: C2 90 ; CLR P1.0

MACHINE CODE EXPLAINED

D2 is the opcode for SETB bit | C2 is the opcode for CLR bit | 90 = bit address for P1.0
The compiler/assembler converts human-readable code into these hex values automatically.
3. Programming Standards Overview
The embedded industry has multiple standards and guidelines that govern how software is written,
tested, and validated.

Standard/Framework Full Form Domain

MISRA Motor Industry Software Reliability Automotive, Aerospace,
Association Medical
AUTOSAR AUTomotive Open System ARchitecture Automotive ECU software
architecture
ASPICE Automotive Software Process Automotive software
Improvement and Capability process
Determination
FUSA / ISO 26262 Functional Safety (Road Vehicles) Safety-critical automotive
systems
CMMI Capability Maturity Model Integration Software process maturity
ANSI-C / ISO C American National Standards Institute C General C language
standardization
CMSIS Cortex Microcontroller Software ARM Cortex-M
Interface Standard microcontrollers
CERT-C SEI CERT C Coding Standard Secure coding for C
programs
BARR-C Barr Group Embedded C Coding Embedded bug reduction,
Standard style guide
JPL Standard Jet Propulsion Laboratory Coding NASA/Space mission
Standard software

4. Embedded V-Model (Standard SDLC Process)

The V-Model is the standard Software Development Life Cycle (SDLC) model used in embedded
systems development. It pairs each development phase with a corresponding testing phase.

V-MODEL CONCEPT
The LEFT side = Developer's Life Cycle (design going downward)
The RIGHT side = Tester's Life Cycle (testing going upward)
Each level on the left directly maps to a test level on the right (connected by dotted lines)

Development Phase (Left) Corresponding Test Deliverable

Phase (Right)
Business Requirements Functional Testing Product Requirements Doc
(PRD)
System Specifications System Testing Engineering Validation &
Testing (EVT)
High Level Design (HLD) Integration Testing Design Validation & Testing
(DVT)
Low Level Design (LLD) Unit Testing Production Validation &
Testing (PVT)
Coding (Bottom) — Mass Production (MP) / End-
of-Life (EOL)

TESTING LEVELS EXPLAINED

Unit Testing: Tests individual functions/modules in isolation.
Integration Testing: Tests how modules interact with each other.
System Testing: Tests the complete integrated system.
Functional Testing: Validates the system against business/user requirements.
5. ANSI-C and ISO C Standards
5.1 ANSI-C (C89) — The Old Standard
ANSI C refers to the first widely adopted C language standard, formally known as ANSI X3.159-
1989 (hence called C89). In 1983, the American National Standards Institute (ANSI) commissioned
a committee to standardize C. Although ISO is now the governing body, the term 'ANSI C' still refers
to this foundational standard.

Key Features of ANSI C (C89)

• Standardization
• Function Prototypes
• Standard Libraries
• Data Types
• Preprocessor Directives
• Control Structures
• Structs and Unions

5.2 C89 vs C99 — Critical Differences

C89 (ANSI-C) C99 (ISO)
No // line comments (only /* */ // single-line comments are supported
block comments)
Declarations must come Declarations can be mixed with statements anywhere
before ALL statements in a
block
Compilers remember first 31 Compilers remember first 63 characters of identifiers
characters of identifiers
No _Bool type available _Bool type + stdbool.h macros (true/false) added
No inline, restrict keywords 5 new keywords: inline, restrict, _Bool, _Complex, _Imaginary
No <stdint.h> — no fixed-width <stdint.h> added: uint8_t, uint16_t, int32_t etc.
integer types
Old-style function definition: int New style: int add(int a, int b) {} — parameters typed inline
add(a,b) int a,b;{}

/* C89 style (deprecated) */ /* C99 style (correct) */

int add(a, b) int add(int a, int b)
int a, b; {
{ return a + b;
return a + b; }
}

/* In C89: declarations MUST come first */

void foo() {
int x = 5; /* OK in C89 */
printf("%d", x);
int y = 10; /* ERROR in C89, OK in C99 */
}
5.3 ISO C Evolution Timeline
Standard Year & Key Additions
ANSI X3.159 (C89) 1989 — First formal standard. Function prototypes, basic
libraries.
ISO/IEC 9899:1990 (C90) 1990 — ISO adoption of C89. Essentially identical.
ISO 9899:1999 (C99) 1999 — // comments, mixed declarations, <stdint.h>,
<stdbool.h>, inline, restrict, _Bool
ISO 9899:2011 (C11) 2011 — Multi-threading support, anonymous structs/unions,
_Noreturn, improved Unicode
ISO 9899:2018 (C17) 2018 — Bug fixes and clarifications to C11. No major new
features.

EXAM TIP — C99 NEW HEADERS

C99 Headers to know: <stdbool.h> (true/false), <stdint.h> (uint8_t etc.), <inttypes.h>,
<complex.h> (complex number math), <tgmath.h> (type-generic math), <fenv.h> (floating-point
flags)
6. CMSIS — Cortex Microcontroller Software Interface
Standard

6.1 What Is CMSIS?

CMSIS (also expanded as Common Microcontroller Software Interface Standard) is a vendor-
independent hardware abstraction layer (HAL) developed by ARM for Cortex-M based processors. It
is a set of APIs, software components, tools, and workflows.

Goals of CMSIS
• Simplify software reuse across different Cortex-M MCUs
• Reduce the learning curve for new microcontroller developers
• Speed up project build and debug cycles
• Reduce time-to-market for new embedded applications
• Enable interoperability of software components from multiple silicon vendors

KEY CONCEPT
CMSIS is vendor-INDEPENDENT — same API works across Silicon Labs, Atmel/Microchip,
STMicroelectronics, NXP, Texas Instruments, Infineon, Nuvoton, Freescale, Fujitsu, Cypress.

6.2 CMSIS Core Components

Component What It Provides Example
CMSIS-Core Standardized access to ARM Cortex SysTick, NVIC, MPU, System
processor core and peripheral Control Block
registers
CMSIS-Driver Generic peripheral driver interfaces Driver_interface.h,
(middleware) Driver_Common.h, VIO
CMSIS-RTOS2 Common API for Real-Time Thread management,
Operating Systems semaphores, queues
CMSIS-DSP Compute library for digital signal FFT, filters, matrix operations
processing
CMSIS-NN Neural network kernels for Cortex-M Convolution, activation, pooling
(machine learning) layers
CMSIS-Pack Software packaging and delivery Devices, boards, software
mechanism packs on [Link]
CMSIS-SVD Peripheral description for debuggers Register maps visible in IDE
debugger
CMSIS-DAP Debug access protocol (hardware JTAG/SWD debug interface
debug) standard

6.3 CMSIS Core Library — Three Key Capabilities

1. Hardware Abstraction Layer (HAL)
 • Defines standardized definitions for SysTick, NVIC, System Control Block registers, MPU
(Memory Protection Unit)
• Core access functions like Bus interfaces are abstracted

2. Header File Organization

• Specific naming conventions for device-specific interrupts
• Standardized API references and data structures across all Cortex-M chips

3. System Initialization
• SystemInit(): function called before main()
• Sets up the clock system, configures the SysTick timer for the specific device

REFERENCE
CMSIS GitHub: [Link]
CMSIS Docs: [Link]
7. MISRA Coding Standard
7.1 What Is MISRA?
MISRA stands for Motor Industry Software Reliability Association. MISRA-C is a set of coding
guidelines for C and C++ that promote safety, security, and reliability in embedded system software.
It defines a 'safe subset' of the C language — restricting or removing constructs that are prone to
undefined behavior, ambiguity, or implementation-specific results.

7.2 MISRA History

Version Details
MISRA C: 1998 First public release. Born from Rover/Ford automotive projects.
MISRA C: 2004 Major revision. 141 rules. Most widely used version in industry.
MISRA C++: 2008 Extension of MISRA principles to C++ for automotive use.
MISRA C: 2012 Current major C version. Revised rule categories. Supports C99.
MISRA C: 2023 Latest update. Automated compliance tooling improvements.

7.3 MISRA Guideline Classification

By Verification Type
• Rule
• Directive

By Compliance Obligation
• Mandatory
• Required
• Advisory

EXAMPLES TO REMEMBER
MISRA C:2012 Rule 11.1 (Decidable Rule): Conversions shall not be performed between a
pointer to a function and any other type.
MISRA C:2012 Dir 1.1 (Directive): Any implementation-defined behavior on which the output of
the program depends shall be documented.

7.4 MISRA Rule Categories Summary

Category Category Name Example Rule
No.
1 ENVIRONMENT Compiler/linker must support 31-char significance
and case sensitivity for external identifiers.
2 LANGUAGE EXTENSIONS Source code shall only use /* ... */ style comments
(no // in C89 MISRA context).
 3 DOCUMENTATION All usage of implementation-defined behavior shall
be documented.
4 CHARACTER SETS Only escape sequences defined in ISO C standard
shall be used.
5 IDENTIFIERS A typedef name shall be a unique identifier.
6 TYPES Bitfields shall only be defined as unsigned int or
signed int.
7 CONSTANTS Type shall be explicitly stated when
declaring/defining an object or function.
9 INITIALIZATION All automatic variables shall have been assigned a
value before being used.
10 ARITHMETIC TYPE Implicit type conversions must be safe and
CONVERSIONS documented.
11 POINTER TYPE No conversion between function pointers and other
CONVERSIONS types (Rule 11.1).
16 FUNCTIONS Functions shall not call themselves — directly or
indirectly (no recursion).
19 PREPROCESSING Macros, includes, and conditional compilation rules.
DIRECTIVES

7.5 MISRA Code Examples

Example 1: Ambiguous vs Safe Code (Rule 13.2)
Rule 13.2 states: The value of an expression and its persistent side effects shall be the same under
all permitted evaluation orders.

/* AMBIGUOUS — violates MISRA (evaluation order undefined) */

val = n++ + arr[n]; /* n is modified AND used — undefined behavior! */
val = fun1() + fun2(); /* Order of fun1/fun2 execution is unspecified */

/* SAFE — MISRA compliant */

val = n + arr[n+1];
n++; /* n incremented AFTER use */

val = fun1();
val += fun2(); /* Explicit sequential execution */

Example 2: Unreachable Code (Rule 2.1) — Defensive Coding Exception

#if (MARKET == EUR)
input = ON; /* Input not connected for EUR market */
#elif (MARKET == JPN)
input = g_current_data; /* Sensor connected for JPN market */
#endif

if (input == ON) { /* Reachable for EUR and JPN */ }

else { /* Only reachable for JPN */ }

/* Rule 2.1: A project shall not contain unreachable code */

/* Deviation rationale: Defensive coding for market-specific builds */
IMPORTANT — EXAM FAVORITE
No Recursion Rule: MISRA Rule 16 says functions shall NOT call themselves, directly or
indirectly.
This is because recursion can cause stack overflow — catastrophic in embedded safety systems.
This same rule also appears in the 'Basics of Programming' slide for Embedded C.
8. AUTOSAR — Automotive Open System Architecture
8.1 What Is AUTOSAR?
AUTOSAR (AUTomotive Open System ARchitecture) is a global standard partnership founded by
nine major automotive companies to define a common software architecture for automotive ECUs
(Electronic Control Units). It separates application software from hardware, enabling reuse and
portability.

FOUNDERS — REMEMBER THESE

9 founding partners: BMW, Bosch, Continental, Ford, GM, Mercedes-Benz, Stellantis, Toyota,
Volkswagen Group.

8.2 Why AUTOSAR Is Needed

A modern car contains 70+ ECUs managing everything from engine to airbags to infotainment.
Without a standard, each ECU would require custom software — making integration, updates, and
safety validation extremely costly.

Domain ECU Examples

Engine & Powertrain Engine Control, Automatic Transmission, Gear Selector,
Breaking Control
Steering Steering Column, Steering Wheel, Electric Power Steering,
Parking Sensor
Body & Lighting Left/Right Headlight, External Light Control, Rain/Sun Sensor,
Alarm Unit
Comfort Seat Controls, Electronic Mirrors, Power Roof/Sunroof, Air
Conditioning
Doors & Access Driver Door, Passenger Door, Passive Entry, Driver Seat ECU
Safety Air Bag Unit, Adaptive Cruise Control, Tyre Pressure, Vision
Enhancement
Infotainment Integrated Cell Phone, GPS, Infotainment ECU
Communications CAN Bus, LIN Bus, FlexRay — Distribution Gateway

8.3 AUTOSAR Classic Platform Architecture

The AUTOSAR Classic Platform has three main layers running on a microcontroller:
• Application Layer (SWC)
• Runtime Environment (RTE)
• Basic Software (BSW)

VFB CONCEPT — EXAM FAVORITE

Virtual Function Bus (VFB): An abstraction where SWCs communicate as if on a logical bus.
In reality, the VFB is mapped to the RTE on each physical ECU.
Example: Light Control SWC sends a signal that is received by the Dimmer SWC via RTE.
8.4 AUTOSAR Functional Safety Features (ISO 26262)
• Memory Partitioning
• Defensive Behavior
• Dual Microcontroller Architecture
• Program Flow Monitoring
• End-to-End (E2E) Communication Protection

8.5 AUTOSAR Architecture Evolution

Release Key Changes
Release 2.1 Communication Services, Com Manager, FlexRay Interface
introduced.
Release 3.0 State managers added for CAN, LIN, FlexRay. Reduced
complexity. More mature BSW.
AUTOSAR Classic For deeply embedded systems — high predictability, safety,
security, responsiveness.
AUTOSAR Adaptive For high-compute platforms (ADAS, autonomous driving) — runs
on POSIX OS, C++14.
9. Principles for Programming in Embedded Systems
Principle 1: Code Efficiency and Optimization
• Memory Management
• Execution Speed
• Resource Constraints

Principle 2: Modular Programming

• Function Decomposition
• Reusability
• Maintainability

Principle 3: Version Control

• Track Changes
• Collaboration
• Rollback

Principle 4: Industry Standards and Safety

• Adhere to Guidelines
• Compliance
• Safety-Critical Systems

Principle 5: Rigorous Testing

• Unit Testing
• Integration Testing
• Stress Testing
• Real-Time Testing

10. Embedded C Programming Basics (Coding Rules)

Rule Explanation
Formatting Use consistent brace style (K&R or Allman) and 4-space
indentation.
Readability Do not enforce an absolute 80-character line limit — use
judgment.
Coding Standard Pick a standard (MISRA, BARR) and stick to it consistently.
Commenting Write extensive comments explaining WHY, not just WHAT.
Static global variables Use for singleton states; avoid unnecessary global declarations.
Initialize all objects Objects/variables shall be initialized at declaration wherever
possible.
Use const Pointers/variables not intended to be modified shall be declared
const.
Avoid Magic Numbers Use #define or enum constants instead of raw numbers like 42
or 0xFF.
Use Enums for State Machines Enums make state machine code readable and type-safe.
Descriptive names Variables and functions must have clear, descriptive names.
void for no params All functions that take no parameters must be declared void: int
foo(void)
Static internal functions Use static functions for module-internal code; don't expose in
headers.
One screen rule Functions must fit on one screen. If not, break into smaller
functions.
Single responsibility Each function shall do exactly one thing — inferred from its
name.
No recursion Functions shall NOT call themselves, directly or indirectly
(MISRA Rule 16).
11. C Programming Memory Management Techniques
Technique Description
Segmentation Physical memory is divided into variable-length chunks called
segments. Each segment has a defined start address and
length. Used for code, data, stack, heap separation.
Paging Memory is organized into equal-sized pages (e.g., 4KB each).
Simpler than segmentation. Used by OS for virtual memory
management.
Swapping OS moves process data in/out of RAM to/from secondary
storage (swap space) when RAM is insufficient. Involves 'swap
in' and 'swap out' operations.

EMBEDDED MEMORY NOTE

In embedded systems, dynamic memory (malloc/free) is often avoided due to fragmentation risk.
Static and stack allocation are preferred for predictable, deterministic memory usage.
Segmentation example: One Segment of Eight Bytes at address 0x00 = FF AA FF AA FF 55 22
00
12. Engineering Roles in Embedded Industry
Role Responsibilities
Hardware Development Schematics design, PCB layout, Field Application Engineering
Engineer (FAE)
Software Development Software design, coding, software integration
Engineer
Software Testing Engineer Unit testing, functional testing of software modules
HIL Testing Engineer Hardware-in-Loop testing — tests ECU software with real
hardware signals
SIL Testing Engineer Software-in-Loop testing — tests software logic without physical
hardware
Design Engineer (Architect) System architecture, HLD/LLD design, component selection
Firmware/Application Engineer Writing low-level firmware for specific MCUs and peripherals
Process Engineer / Manager Delivery, Program, Project, Quality management roles
Non-Technical / Translation Translates technical documents across languages for global
Engineer teams
13. Quick Revision — Exam Ready Summary

TOP 10 EXAM POINTS

ANSI-C = C89 | ISO C90 same as C89 | C99 added //, mixed declarations, <stdint.h>,
<stdbool.h>
CMSIS = ARM's vendor-independent HAL for Cortex-M | Components: Core, Driver, RTOS2,
DSP, NN, Pack
MISRA = Safety coding guidelines | Rule (tool-checkable) vs Directive (process/judgment)
MISRA compliance: Mandatory (no exceptions) > Required (with deviation) > Advisory (where
practical)
AUTOSAR = Layered architecture: Application SWC | RTE (VFB) | Basic Software (BSW) |
Microcontroller
AUTOSAR founded by 9 companies: BMW, Bosch, Continental, Ford, GM, Mercedes, Stellantis,
Toyota, VW
V-Model: Business Req <-> Functional Test | System Spec <-> System Test | HLD <->
Integration | LLD <-> Unit Test
No Recursion Rule: Both MISRA Rule 16 AND Embedded C basics — functions must not call
themselves
C vs Embedded C: Embedded C is hardware-dependent, resource-limited, no traditional OS
required
MISRA Rule 13.2: val = n++ + arr[n] is WRONG; separate into sequential statements — SAFE

Common MCQ Traps

Wrong Answer (Common Correct Answer
Mistake)
CMSIS stands for Cortex ALSO correctly expanded as Common Microcontroller Software
Microcontroller Software Interface Standard — both are accepted
Interface Standard
ANSI-C supports // comments C89/ANSI-C does NOT support // comments — only C99 and
later
MISRA-C is only for MISRA-C is used in Automotive, Aerospace, AND Medical
automotive industries
AUTOSAR has 2 layers AUTOSAR Classic has 3 layers: Application, RTE, Basic
Software (BSW)
Recursion is allowed in MISRA MISRA Rule 16 explicitly prohibits recursion — direct or indirect
C99 requires declarations C89 requires this; C99 allows mixed declarations and statements
before statements
BARR-C replaces MISRA-C BARR-C is designed to complement and supplement MISRA-C,
not replace it

End of Unit 3 Exam Notes

MIT Academy of Engineering | Embedded Edge AI