Hardware and Software in IoT Design 🛠

IoT devices combine hardware and software, requiring co-design for effective functionality.

• Hardware Components: Include microcontrollers, sensors, actuators, LEDs, voltage

regulators, and capacitors, typically wired on breadboards for prototyping.
• Software Role: Executes on the microcontroller, controlling components (e.g., turning
LEDs on/off). Software must be written with hardware constraints in mind (e.g., LED
current limits).
• Design Challenge: Hardware and software must be designed together. Hardware
selection (e.g., component size, voltage) impacts software, and software must account for
hardware behavior. Changes during design may require swapping components,
necessitating careful planning.
• Key Point: IoT design integrates hardware and software, with designers balancing
component selection and code development to meet system requirements.

Datasheets for Hardware Components 📋

Datasheets provide critical information for selecting and integrating hardware components,
especially integrated circuits (ICs) like microcontrollers.

• Purpose: Datasheets detail physical dimensions, electrical parameters (e.g., voltage,

current), thermal limits, and pin configurations to ensure compatibility with systems like
breadboards.
• Physical Dimensions: Essential for prototyping (e.g., pin spacing must match breadboard
holes at 0.1-inch intervals). Example: Schottky rectifier datasheets include diagrams with
pin sizes and spacing.
• Electrical Parameters: Specify voltage/current limits to ensure compatibility (e.g., a 5V
microcontroller vs. a 3.3V component requires voltage stepping).
• Complexity: IC datasheets (e.g., for microcontrollers) can be dense (150–1000 pages),
but only key sections (e.g., pin functions, voltage) are typically needed for prototyping.
Simpler components like resistors have minimal datasheet requirements.
• Accessing Datasheets: Found online by searching part numbers with “datasheet” (e.g.,
Google “Schottky Rectifier datasheet”).
• Challenge: Reading datasheets is complex, but critical for avoiding mismatches.
Component sourcing has shifted online due to the decline of hobbyist stores like Radio
Shack, increasing reliance on datasheets to avoid ordering errors.
• Key Point: Datasheets are vital for ensuring hardware compatibility and functionality in
IoT prototyping, requiring designers to extract relevant parameters.
Microcontroller Characteristics for IoT 💾
Microcontrollers are central to IoT systems, and selecting the right one involves evaluating key
characteristics based on project constraints.

• Selection Criteria: IoT systems are tightly constrained (unlike over-engineered

desktops), requiring the cheapest microcontroller that meets minimum requirements.
Choices may be pre-determined (e.g., company uses Freescale), but many options exist
within brands.
• Key Characteristics:
o Datapath Bitwidth: Determines number size (e.g., 8-bit for Arduino, sufficient
for simple tasks; 64-bit for higher accuracy/throughput). Impacts data processing
capacity.
o Input/Output Pins: Critical for connecting to components. Limited pins (e.g., 40
needed) are a bottleneck, requiring early design planning to ensure sufficient pin
availability.
o Performance: Varies by application. Human-interfacing IoT devices (e.g., 30
frames/second video, 22 kHz audio) need less performance than video processing,
allowing slower, cheaper microcontrollers.
o Timers: Essential for real-time tasks (e.g., sampling sound every millisecond).
Timer accuracy (e.g., 8-bit vs. 16-bit) impacts precision.
o Analog-to-Digital Converters (ADCs): Convert analog phenomena (e.g., light
brightness, sound volume) to digital for processing. Most microcontrollers include
ADCs, but Raspberry Pi lacks one, limiting analog input capabilities.
o Low Power Modes: Common for battery-powered IoT devices. Allow
intermediate states (e.g., reduced clock rate, memory retention) to save power,
critical for long battery life.
o Communication Protocol Support: Protocols like UART, I2C, and SPI enable
microcontroller communication with other ICs (e.g., SRAM). Most modern
microcontrollers support multiple protocols, but compatibility must be verified.
• Key Point: Microcontroller selection for IoT balances cost, performance, and features
like pins, ADCs, and low power modes, tailored to application-specific constraints.

Microcontroller Storage Elements 🗄

Storage elements in microcontrollers manage data and programs, with trade-offs in speed, cost,
and size.

• Types of Storage:
o Registers: Fastest, store single values (e.g., 32-bit number). Expensive due to
chip area, limited to special-purpose (e.g., program counter) or general-purpose
 tasks (e.g., arithmetic). Register files group registers (e.g., 32 registers) for fast
access.
o Cache Memory: Larger and slower than registers (e.g., 1 Mbit), takes ~1 clock
cycle to access. Uses Harvard architecture with separate data and instruction
caches. Cheaper than registers but still on-chip.
o Main Memory: Off-chip, larger (gigabytes), and slower (e.g., 100 clock cycles
access time). Connected via system bus, used in desktops but less common in
microcontrollers.
o Flash Memory: Non-volatile (retains data without power), used for program
storage (e.g., 256 KB in AVR ATmega2560). Common in thumb drives and
microcontrollers.
o EEPROM: Non-volatile, similar to flash, for persistent data storage.
o SRAM: Volatile random-access memory for temporary data storage.
• Von Neumann Bottleneck: In Von Neumann architecture, slow main memory access
(e.g., 100 clock cycles) bottlenecks performance. Caches and registers mitigate this by
storing frequently used data.
• IoT Relevance: Microcontrollers prioritize flash and SRAM for efficiency.
Compilers/interpreters (e.g., C, Python) manage storage allocation, reducing programmer
burden in IoT development.
• Key Point: Storage elements balance speed, cost, and capacity, with flash and registers
critical for IoT microcontrollers, while caches avoid bottlenecks.

Software Processing for Microcontrollers 💻

Microcontroller software is written in high-level languages but executed as machine code,
requiring translation via compilation or interpretation.

• Machine Language: Microcontrollers execute binary machine code (zeros and ones),
specific to the processor (e.g., Intel x86, AVR ATmega). Instructions are simple (e.g.,
add, subtract).
• Assembly Language: Human-readable mnemonics (e.g., add R1, R2, R3) map one-to-
one to machine code. Used rarely due to complexity.
• High-Level Languages: C, C++, Python, etc., offer programmer-friendly constructs
(loops, variables). Translated to machine code before execution.
• Compilation (C, C++): Converts high-level code to machine code once, producing an
executable. Faster execution but requires explicit declarations (e.g., int x). Used in
Arduino.
• Interpretation (Python): Converts code to machine code at runtime, slower but easier to
program (e.g., no variable declarations). Used in Raspberry Pi.
• Toolchain: Sequence of software tools for code translation:
o Host: Laptop/desktop for writing code.
 o Cross Compiler: Converts C to assembly for the target microcontroller (e.g.,
AVR ATmega).
o Assembler: Converts assembly to machine code, producing an object file.
o Linker: Integrates library functions (prewritten code) with the object file, creating
an executable.
o Programmer: Transfers executable to microcontroller’s flash memory via USB.
• Libraries: Simplify coding by hiding microcontroller details (e.g., Arduino/Raspberry Pi
libraries), but may limit access to advanced features. Detailed datasheet review allows
bypassing libraries for customization.
• Key Point: Software translation via compilation (C/C++) or interpretation (Python)
enables IoT programming, with toolchains and libraries streamlining development.

C/C++ vs. Python in IoT 🐍

C/C++ and Python are common for IoT, with distinct trade-offs in embedded systems.

• C/C++ (Arduino):
o Compiled languages, producing fast executables.
o Require explicit management (e.g., variable types, memory allocation
with malloc, freeing memory).
o Offer fine-grained control, allowing programmers to optimize for efficiency based
on context, critical for resource-constrained IoT devices.
• Python (Raspberry Pi):
o Interpreted language, slower due to runtime translation.
o Simplifies programming by handling variable types and memory management
automatically.
o Less efficient but easier for rapid prototyping and less critical applications.
• Toolchain Differences:
o C/C++: Compiler → Assembler → Linker → Programmer. One-time compilation
for efficiency.
o Python: Interpreter runs on the target, translating code at runtime, increasing
overhead but reducing programmer effort.
• Key Point: C/C++ suits performance-critical IoT applications, while Python excels in
ease of use for prototyping, with toolchains reflecting these priorities.
Operating Systems in IoT 🌍
Operating systems (OS) manage resources in complex IoT devices but are not always needed.

• Role: An OS sits between application code and hardware, managing hardware access,
multiple programs, and user interfaces.
• Presence in IoT:
o Arduino: Too slow (e.g., 8 MHz) to support an OS, running one program directly
on hardware.
o Raspberry Pi: Faster (e.g., 1 GHz), supports OS (e.g., Linux) for multitasking
and command-line interfaces.
• Functions:
o Multitasking: Manages multiple applications/processes, interleaving execution to
appear simultaneous. Critical for complex IoT devices (e.g., web-controlled car).
o Resource Management: Allocates CPU, memory, ADCs, timers, and network
access fairly among processes.
o User Interface: Provides command-line or minimal GUI in IoT, unlike desktop
OS (e.g., Windows).
• Example (Web-Controlled Car):
o Tasks: Stream video, service motion buttons (forward/back), detect obstacles,
auto-brake.
o OS Benefit: Separates tasks into independent processes (e.g., video streaming,
button handling), interleaving them to simplify programming. Without an OS,
programmers must manually interweave tasks, increasing complexity.
• Trade-Offs:
o Cost: OS consumes clock cycles and memory, requiring faster processors and
increasing costs.
o Necessity: Simple IoT devices (e.g., Arduino-based) avoid OS for efficiency,
while complex devices (e.g., Raspberry Pi with Wi-Fi and web servers) benefit
from OS multitasking.
• Key Point: Operating systems enhance multitasking in complex IoT devices but add
overhead, making them optional based on system requirements.

Overall Takeaways 🌟
Microcontrollers are the core of IoT devices, requiring careful selection based on
characteristics like bitwidth, pins, performance, ADCs, timers, low power modes, and protocol
support to meet tight constraints. Datasheets are essential for choosing compatible hardware,
detailing dimensions, electrical parameters, and pin functions. Storage elements (registers,
cache, flash, SRAM) balance speed and cost, with flash critical for non-volatile program storage.
Software is translated from high-level languages (C/C++, Python) to machine code via
compilation or interpretation, with C/C++ offering efficiency for Arduino and Python easing
development on Raspberry Pi. Toolchains streamline this process, integrating libraries for
simplicity. Operating systems support multitasking in complex IoT systems (e.g., Raspberry Pi)
but are omitted in simple devices (e.g., Arduino) to save resources. Together, these elements
enable efficient, application-specific IoT design, balancing hardware, software, and system
constraints for optimal performance and cost.