5.3  Selecting a Microcontroller from Requirements

Begin with the workload and deployment environment. A defensible selection records:

• maximum and typical execution load, deadline, jitter, and interrupt rate;

• flash, SRAM, persistent data, stack, heap, and update-slot requirements with margin;

• ADC channels and quality, DAC, comparators, timers, PWM, capture, encoder, and motor-control needs;

• UART, I²C, SPI, CAN, USB, Ethernet, and wireless instances and simultaneous pin mapping;

• voltage, current, power modes, wake time, battery, and radio-current peaks;

• operating temperature, electromagnetic environment, package, connector, and enclosure;

• secure boot, protected key storage, cryptographic acceleration, debug locking, and update support;

• toolchain, debugger, RTOS or SDK maturity, documentation, errata, test support, and team competence;

• component lifecycle, second sources, certification, unit volume, and total product cost.

Figure 5.1. Conceptual comparison of microcontroller development-board classes. Regulators, USB interfaces, flash, antennas, and pin routing are board-level resources; exact features vary by model.

Headline CPU frequency is rarely decisive. A slower MCU with a suitable timer, DMA channel, encoder interface, and ADC trigger may outperform a faster part forced to implement those functions in software. Verify that required peripherals can be used simultaneously; development-board pin labels can conceal shared functions and conflicts.

MCU firmware interacts with memory-mapped peripheral registers. Flash stores executable code and constants; SRAM stores stacks, variables, buffers, and dynamic state. Some devices add caches, tightly coupled memory, external-memory controllers, EEPROM or emulated EEPROM, and memory-protection units.

Stack overflow and buffer overwrite can silently corrupt control state. Avoid unbounded recursion, unbounded queues, and unchecked copying. Measure high-water marks where supported. Dynamic allocation can be acceptable when bounded and designed, but uncontrolled allocation and fragmentation are difficult to justify in long-lived real-time firmware.

Flash has finite erase endurance. Persistent counters should use wear-aware storage, journaling, or a dedicated nonvolatile strategy. A power loss between erasing and rewriting configuration can destroy both old and new values unless redundant, checksummed, and committed atomically.

Figure 5.2. Conceptual MCU architecture. Exact bus, cache, DMA, and peripheral relationships determine timing and concurrency behavior.

5.5  GPIO, Timers, ADC, PWM, and DMA

GPIO registers control direction, output state, pull devices, drive strength, and alternate peripheral functions. Configure the safe output level before enabling a pin as an output where hardware allows. At reset, pins may be inputs or have boot-related functions; external circuitry must keep actuators safe during this interval.

Timers provide periodic interrupts, input capture, output compare, quadrature decoding, PWM, and watchdog timing. Hardware capture timestamps an edge more accurately than a delayed software read. PWM controls average delivered energy or a driver’s command, but switching frequency, resolution, dead time, load dynamics, and filtering matter.

An ADC converts an analog input relative to a reference. Acquisition time, source impedance, reference stability, input range, sampling trigger, calibration, noise, and effective number of bits determine useful performance. Never connect a voltage outside the permitted input range.

Direct memory access (DMA) moves data between peripheral and memory without CPU action for every item. DMA reduces interrupt load and timing jitter but introduces ownership and coherency problems: firmware must know which buffer is being filled, which is ready, and whether caches require maintenance. DMA completion does not prove that data are physically valid.

5.6  Interrupts, Concurrency, and Real-Time Behavior

An interrupt service routine (ISR) should normally do the minimum bounded work needed: capture state, clear the correct source, place data into a safe buffer or signal a task, and return. Blocking network calls, long formatting, dynamic allocation, or unbounded loops inside an ISR increase latency and can starve lower-priority work.

Shared state between ISR and main code or tasks requires synchronization. volatile can prevent certain compiler optimizations but does not make a compound operation atomic, create a memory barrier for every architecture, or protect invariants. Use architecture and RTOS primitives deliberately.

Important timing quantities are:

• period: intended interval between activations;

• latency: delay from event to response;

• jitter: variation in timing;

• execution time: processor time required;

• deadline: latest acceptable completion; and

• worst-case execution time: justified upper bound under defined conditions.

Measure timing using a hardware timer, trace facility, or oscilloscope/logic-analyzer pin toggle. Serial printing changes timing and is not a neutral measurement technique.

5.7  Bare Metal, Superloops, and RTOS Designs

A cooperative superloop repeatedly executes bounded tasks:

Listing 5.1.  Non-blocking cooperative scheduling concept

for (;;) {
    uint32_t now = monotonic_ms();

    if (deadline_reached(now, next_sample)) {
        next_sample += SAMPLE_PERIOD_MS;
        start_sensor_conversion();
    }
    service_sensor_state_machine(now);
    service_communication(now);
    service_actuator_state_machine(now);
    update_health_and_watchdog(now);
}

This listing is scheduling pseudocode: the platform must supply the named functions, initialize the first deadline, and define an overrun policy. A fixed-width counter wraps, so deadline_reached must use a documented wrap-safe comparison with intervals shorter than half the counter range. Decide whether a missed period is skipped or caught up; do not create an uncontrolled burst of conversions. This structure can be reliable when every activity is bounded and non-blocking.

An RTOS adds preemptive tasks, priorities, timers, queues, semaphores, and event mechanisms. It helps organize concurrency but does not automatically make firmware real-time or race-free. Priority inversion, deadlock, stack exhaustion, queue overflow, and starvation remain design concerns.

Assign task priorities according to deadlines and consequence, not organizational importance. Avoid allowing a low-priority diagnostic task to hold a resource required by a high-priority control task.

A useful partition assigns the MCU deterministic and safety-adjacent work and Linux complex, changing, network-facing work.

Partitioning does not contain faults unless authority is explicit. Define which node may command each actuator, whether the MCU can reject Linux commands, how command freshness is evaluated, and what happens during disagreement, restart, update, or corrupted communication.

The parser must bound length before allocation or copying, enforce a receive timeout, reject unsupported versions and types, recover after corrupt bytes, and never interpret a partial frame as a command. Define numeric size, signedness, byte order, scaling, units, and string encoding.

The protocol specification should define:

• physical and link settings, including voltage standard and baud rate;

• byte-level framing and escaping;

• byte order and exact field widths;

• protocol and message version compatibility;

• message types, direction, permissions, and response semantics;

• units, scale factors, coordinate frames, valid ranges, and sentinel policy;

• sequence behavior, acknowledgement, timeout, retry, and duplicate handling;

• startup handshake and capability discovery;

• maximum payload, rate, buffering, and overflow behavior;

• error codes, diagnostics, reset reason, and health reporting; and

• authentication and replay protection where commands cross a trust boundary.

Versioning should support an intentional compatibility policy. Rejecting an unknown version is safer than interpreting fields under the wrong meaning. Capability negotiation can allow old and new nodes to agree on a supported subset, but negotiation itself must be bounded and testable.

Listing 5.2.  Illustrative bounded frame header

#include <stdint.h>
#include <stdbool.h>
#include <stddef.h>

/* Implement from the protocol message-type table. */
bool message_type_is_supported(uint8_t type);

typedef struct {
    uint8_t  version;
    uint8_t  type;
    uint16_t source_id;
    uint32_t sequence;
    uint16_t payload_length;
} frame_header_t;

enum { MAX_PAYLOAD = 256 };

bool header_is_valid(const frame_header_t *h) {
    return h != NULL &&
           h->version == 1 &&
           h->payload_length <= MAX_PAYLOAD &&
           message_type_is_supported(h->type);
}

Do not transmit a C structure directly as a portable wire format. Padding, alignment, compiler behavior, and native byte order can differ. Serialize each field explicitly.

A checksum or cyclic redundancy check detects many accidental transmission errors. It does not prove who sent a message, because an attacker can modify the data and calculate a new CRC. Authentication requires a cryptographic message authentication code or digital signature with protected keys and a defined key-management process.

Authentication alone does not stop replay of an old valid command. Include a sequence, nonce, session context, or timestamp under authenticated protection, and define restart and resynchronization behavior. Encryption protects confidentiality but is not a substitute for authorization or safe command validation.

5.12   Sequence Numbers, Acknowledgement, and Duplicates

Sequence numbers reveal gaps, repetition, and order within a defined source and session. They do not prove delivery or integrity. Sequence values wrap and may reset when a node loses state, so combine them with persistent device identity and boot/session identifier.

An acknowledgement should state what has been accepted: bytes received, frame validated, command accepted, command completed, or data durably stored. These are different guarantees. If an acknowledgement is lost, the sender may repeat the request, so command handling must be idempotent or deduplicated.

“Set motor target to zero with command ID 482” is an idempotent state-setting request: repeating it leaves the same target. Deduplication additionally requires remembering accepted IDs within a defined source/session and retention window; storing only the most recent ID cannot reject every delayed older request. “Move forward 10 cm” can repeat physical motion unless defined as a unique operation with remembered completion state.

5.13   Watchdogs, Brownout, Reset, and Safe Startup

A hardware watchdog resets or constrains a controller that fails to demonstrate health within a configured interval. Refresh it only after critical tasks have met their health conditions. A dedicated low-priority “watchdog task” that always refreshes can conceal a deadlocked control task.

Select the watchdog interval above justified worst-case healthy execution but below the maximum tolerable uncontrolled time. Test it by deliberately blocking or disabling critical work. Record reset cause, firmware version, boot count, and persistent fault count before evidence is overwritten.

Brownout detection prevents execution at inadequate supply voltage. Supply dips can corrupt computation, communication, flash operations, and actuator outputs before a complete reset occurs. External supervisors may provide stronger guarantees than internal brownout circuits.

At reset:

1. external hardware must keep dangerous outputs inactive;
2. firmware sets safe output levels before enabling drivers;
3. reset cause and persistent state are validated;
4. peripherals and communication are initialized;
5. self-tests and configuration checks run;
6. the node reports identity, version, capability, and health; and
7. command authority is accepted only after READY criteria pass.

MCU oscillators have frequency error that varies with tolerance, temperature, voltage, and aging. If relative frequency error is ε, accumulated time error grows approximately as

A 20 ppm clock can accumulate about 1.7 seconds per day under the conditions corresponding to that error. Synchronization corrects or estimates clock relationship; it does not make message latency disappear.

Possible sources include Linux host time, GNSS pulse-per-second and time messages, network synchronization, an RTC, or a local monotonic counter. For precise multi-sensor work, estimate offset and drift and timestamp close to hardware acquisition. Pair timestamps with sequences and a synchronization-quality indicator.

Never use adjustable wall time directly for control intervals. Use a monotonic hardware counter for deadlines and durations, and translate to global time with an explicit clock model.

5.15   Buffering and Store-and-Forward

Buffers absorb differences between production and consumption rates, but a finite buffer only postpones overload. Define capacity, item size, maximum age, ordering, durability, overflow policy, and diagnostic counters.

Report dropped count, oldest queued age, high-water mark, and current depth. On reconnection, prevent backlog transmission from starving current safety traffic or overloading the receiver.

5.16   Power and Low-Energy Operation

Average current is not sufficient for design. Wi-Fi transmission, motor-driver switching, sensor heaters, and flash writes create peaks that can reset the MCU. Include regulator transient response, capacitor behavior, wiring resistance, battery impedance, and temperature.

Low-power firmware coordinates sleep state, wake source, retained memory, sensor warm-up, radio association, measurement duty cycle, and clock accuracy. A development board may consume far more than the MCU because of regulators, power LEDs, USB interface chips, and pull resistors.