0% found this document useful (0 votes)
8 views

IoT_Spring_2025_Lecture_Notes

The document provides an introduction to the Internet of Things (IoT) through various case studies, detailing the components, architectures, and design considerations of IoT systems. It explores real-world applications such as ride-hailing services, smart traffic monitoring, smart water meters, and sports vests, highlighting their key components and processing methods. Additionally, it discusses the importance of microcontrollers, compilation flow, FreeRTOS, and PCB design in the context of IoT development.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views

IoT_Spring_2025_Lecture_Notes

The document provides an introduction to the Internet of Things (IoT) through various case studies, detailing the components, architectures, and design considerations of IoT systems. It explores real-world applications such as ride-hailing services, smart traffic monitoring, smart water meters, and sports vests, highlighting their key components and processing methods. Additionally, it discusses the importance of microcontrollers, compilation flow, FreeRTOS, and PCB design in the context of IoT development.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 28

Introduction to IoT, IIIT Hyderabad, spring 2025

January 6, 2025
2
Contents

1 Introduction to IoT Using Case Studies 5


1.1 What is an IoT System? . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Case Study 1: Ride-Hailing Services (Uber/Ola) . . . . . . . . . . 6
1.2.2 Case Study 2: Smart Road Traffic Monitoring (Including Air Pol-
lution) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 Case Study 3: Smart Water Meters . . . . . . . . . . . . . . . . . 7
1.2.4 Case Study 4: Sports Vests . . . . . . . . . . . . . . . . . . . . . 7
1.3 Comparative Analysis of Case Studies . . . . . . . . . . . . . . . . . . . . 8
1.4 IoT Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.1 IoT Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.2 Key Parameters for IoT Design . . . . . . . . . . . . . . . . . . . 9
1.5 Key Takeaways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Discussion Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Microcontrollers 11
2.1 Why Do We Need a Microcontroller? Why Not Just Use a Microprocessor? 11
2.1.1 Microcontroller vs. Microprocessor . . . . . . . . . . . . . . . . . 11
2.1.2 Why Do We Need a Microcontroller? . . . . . . . . . . . . . . . . 11
2.1.3 Why Not Just Use a Microprocessor? . . . . . . . . . . . . . . . . 12
2.1.4 When to Use a Microprocessor . . . . . . . . . . . . . . . . . . . . 12
2.1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Introduction to Microcontrollers . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Case Study: ESP32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Case Study: Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Case Study: Particle Photon . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Comparison: ESP32 vs Arduino vs Photon . . . . . . . . . . . . . . . . . 15
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.8 Purpose of SRAM vs Flash Memory on ESP32 . . . . . . . . . . . . . . . 15

3 Compilation Flow: From Sketch to Board 17


3.1 Writing the Sketch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Preprocessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Generating the Binary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5 Uploading to the Board . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.6 Program Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.7 Flow Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3
4 CONTENTS

3.8 Native vs Cross-Compilation . . . . . . . . . . . . . . . . . . . . . . . . . 18


3.8.1 Native Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.8.2 Cross-Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.8.3 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.8.4 Relevance to Arduino . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 FreeRTOS in Compiled ESP32 Binaries 21


4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Why FreeRTOS Is Included in Compiled Binaries . . . . . . . . . . . . . 21
4.3 Components Included in the Binary . . . . . . . . . . . . . . . . . . . . . 22
4.4 Bare-Metal Programming vs FreeRTOS . . . . . . . . . . . . . . . . . . . 22
4.5 How to Confirm FreeRTOS in Your Binary . . . . . . . . . . . . . . . . . 22
4.6 Advantages of Including FreeRTOS . . . . . . . . . . . . . . . . . . . . . 22
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 PCBs 25
5.1 PCB Design with Microcontrollers: Why and When? . . . . . . . . . . . 25

6 SoCs vs MCUs 27
6.1 Can a Microcontroller Be Considered an SoC? . . . . . . . . . . . . . . . 27
Chapter 1

Introduction to IoT Using Case


Studies

1.1 What is an IoT System?


An Internet of Things (IoT) system is an interconnected network of THINGS. A THING
is any device or object that can:

• Sense: Collect data from its surroundings.

• Process: Analyze and interpret the data.

• Act: Perform an action based on the processed data.

• Communicate: Exchange information with other THINGS (using e.g., Wi-Fi,


LoRaWAN, Cellular).

Together, these THINGS collaborate to achieve a shared objective, making systems


smarter, more efficient, and capable of addressing complex challenges.

IoT Network Architectures


There are multiple ways IoT devices can be connected to form a network, depending on
the system’s design and requirements:

1. Peer-to-Peer Network: Devices communicate directly with each other without


relying on centralized nodes.

2. Star Network: All devices are connected to a central hub, which manages com-
munication and data exchange.

3. Hierarchical Network (Cloud-Fog-Edge): Combines different levels of process-


ing and storage:

• Cloud: Centralized, large-scale analytics and storage.


• Fog: Localized processing close to the devices.
• Edge: Real-time processing directly on the devices.

5
6 CHAPTER 1. INTRODUCTION TO IOT USING CASE STUDIES

1.2 Case Studies


To illustrate the core components and their roles, we explore four real-world IoT applica-
tions: ride-hailing services, smart road traffic monitoring, smart water meters, and sports
vests.

1.2.1 Case Study 1: Ride-Hailing Services (Uber/Ola)


• Overview: Ride-hailing platforms like Uber and Ola use IoT to connect drivers
and passengers efficiently.

• Key Components:

– Sensors: GPS (for location tracking), accelerometer (driver behavior moni-


toring).
– Communication Network: Cellular (4G/5G) for real-time updates.
– Processing:
∗ Cloud: Dynamic pricing, route optimization, and driver-passenger match-
ing.
∗ Edge: Device-based location updates and basic navigation.

• Considerations:

– Latency: Minimal delay is critical for route updates.


– Privacy: Protecting sensitive data like location and payment details.
– Scalability: Handling millions of users simultaneously.

1.2.2 Case Study 2: Smart Road Traffic Monitoring (Including


Air Pollution)
• Overview: IoT-based systems monitor road traffic and air quality to improve
urban planning and reduce pollution.

• Key Components:

– Sensors:
∗ Traffic Cameras: For vehicle detection and traffic density estimation.
∗ Air Quality Sensors: Measure pollutants such as PM2.5 and NOx.
– Communication Network:
∗ LoRaWAN for low-power, wide-area air quality data transfer.
∗ Cellular/Wi-Fi for high-bandwidth traffic camera feeds.
– Processing:
∗ Edge: Basic object detection and filtering in smart cameras.
∗ Cloud: Aggregated traffic analysis and pollution mapping.

• Considerations:
1.2. CASE STUDIES 7

– Bandwidth: High data transmission requirements for video.


– Integration: Combining traffic and pollution data.
– Power Efficiency: Optimizing energy use for remote air quality sensors.

1.2.3 Case Study 3: Smart Water Meters


• Overview: Smart water meters automate the monitoring and management of water
usage.

• Key Components:

– Sensors: Flow sensors for water usage measurement.


– Communication Network: Narrowband IoT (NB-IoT) or LoRaWAN for
low-power communication.
– Processing:
∗ Edge: Basic anomaly detection, such as identifying leaks.
∗ Cloud: Long-term storage for billing and trend analysis.

• Considerations:

– Power Efficiency: Ensuring battery longevity in remote devices.


– Data Volume: Optimizing periodic updates for bandwidth efficiency.
– Real-Time Alerts: Detecting and addressing leaks or unusual usage pat-
terns.

1.2.4 Case Study 4: Sports Vests


• Overview: IoT-enabled sports vests provide real-time monitoring of athletes’
health and performance.

• Key Components:

– Sensors: Heart rate monitors, GPS, accelerometers.


– Communication Network: Bluetooth/Wi-Fi for close-range connectivity.
– Processing:
∗ Edge: Real-time heart rate and motion tracking.
∗ Cloud: Long-term performance analysis and training optimization.

• Considerations:

– Real-Time Feedback: Vital for in-game monitoring.


– Wearability: Lightweight and non-intrusive design.
– Data Fusion: Integrating multiple sensor inputs for meaningful insights.
8 CHAPTER 1. INTRODUCTION TO IOT USING CASE STUDIES

1.3 Comparative Analysis of Case Studies

Aspect Ride-Hailing Smart Road Smart Water Sports Vests


Services Traffic Moni- Meters
toring
Sensors GPS, Ac- Traffic Cameras, Flow Sensors Heart Rate,
celerometer Air Sensors GPS
Communication Cellular LoRaWAN, Cel- NB-IoT, Lo- Bluetooth, Wi-
Network (4G/5G) lular, Wi-Fi RaWAN Fi
Edge Processing Location Up- Object Detec- Leak Detection Real-Time Mon-
dates tion itoring
Cloud Processing Route Optimiza- Traffic Analysis, Billing, Trend Training Recom-
tion Pollution Maps Analysis mendations
Key Considera- Latency, Privacy Bandwidth, Power Effi- Wearability,
tions Power Efficiency ciency, Alerts Data Fusion

1.4 IoT Design Considerations


Designing effective IoT systems requires careful evaluation of the components and archi-
tecture, as well as the parameters impacting performance. The design process can be
divided into two parts: components and parameters.

1.4.1 IoT Components


• Sensors/Actuators:

– Collect data from the environment (e.g., GPS, flow sensors) or act upon the
system (e.g., valves, motors).
– Require optimization for power, durability, and accuracy.

• Edge vs. Cloud Processing:

– Edge Processing:
∗ Ideal for real-time tasks and latency-sensitive operations.
∗ Reduces bandwidth requirements by filtering and processing data locally.
– Cloud Processing:
∗ Suitable for large-scale analytics and storage.
∗ Supports centralized control and integration of complex models.

• Communication Networks:

– Enable data transfer between IoT devices and the processing systems.
– Choice depends on bandwidth needs, power constraints, and range require-
ments (e.g., LoRaWAN, 5G).

• Security and Privacy:


1.5. KEY TAKEAWAYS 9

– IoT devices must implement encryption, secure boot, and robust protocols to
protect against breaches.
– Centralized data (in the cloud) must follow compliance regulations (e.g., GDPR).
• Software Stack:
– Includes on-device software (lightweight OS like FreeRTOS), middleware (for
communication and device management), and cloud platforms (for analytics
and storage).

1.4.2 Key Parameters for IoT Design


• Processing Capability:
– Assess the computational needs of the application.
– High-end applications (e.g., video analytics) require more powerful edge de-
vices and robust cloud infrastructure.
• Communication Requirements:
– Data volume and bandwidth determine the choice of communication protocol.
– For instance, LoRaWAN is suitable for low-data applications, while 5G handles
high-bandwidth needs.
• Real-Time vs Non-Real-Time:
– Real-time applications (e.g., autonomous vehicles) demand ultra-low latency.
– Non-real-time systems (e.g., smart water meters) prioritize power and cost
efficiency.
• Power Efficiency:
– Crucial for battery-powered IoT devices.
– Includes considerations for sleep modes, energy-efficient communication pro-
tocols, and optimized hardware.
• Storage:
– Edge devices may have limited local storage for real-time operations.
– Cloud platforms offer scalable storage but require efficient data synchroniza-
tion.

1.5 Key Takeaways


• IoT Applications span various domains, from transportation to health and envi-
ronmental monitoring.
• Cloud vs. Edge: Choosing the right processing architecture depends on latency,
bandwidth, and power requirements.
• Design Considerations: Effective IoT systems must balance efficiency, scalability,
and privacy.
10 CHAPTER 1. INTRODUCTION TO IOT USING CASE STUDIES

1.6 Discussion Questions


1. What are the trade-offs between processing data on the edge vs. on the cloud in
IoT?

2. How can IoT systems ensure scalability and security in large-scale applications?

3. Propose another application of IoT and identify its core components and consider-
ations.
Chapter 2

Microcontrollers

2.1 Why Do We Need a Microcontroller? Why Not


Just Use a Microprocessor?
2.1.1 Microcontroller vs. Microprocessor
• Microcontroller (MCU): A microcontroller is a compact, self-contained system
that includes a CPU, memory (RAM and flash), and peripherals (I/O
ports, timers, ADCs, etc.) all on a single chip. It is designed specifically for
embedded systems where a specific task or set of tasks needs to be performed
efficiently, often in real-time. Examples: Arduino, STM32.

• Microprocessor (MPU): A microprocessor is primarily a CPU and relies on ex-


ternal components (RAM, ROM, I/O devices, etc.) to function. It is more suited for
general-purpose computing, such as in computers or complex systems requiring
high processing power. Examples: Intel Core i7, ARM Cortex-A processors.

2.1.2 Why Do We Need a Microcontroller?


1. Cost-Effectiveness: Microcontrollers are cheaper since they integrate everything
needed for control tasks on a single chip. In contrast, microprocessors require
additional components like external RAM, which increases cost and complexity.

2. Compact and Power-Efficient: MCUs are smaller and consume less power, mak-
ing them ideal for low-power, battery-operated devices like remote controls or
IoT devices.

3. Real-Time Control: Many embedded applications, like controlling motors or


reading sensor data, require real-time performance. MCUs have dedicated hard-
ware (like timers and ADCs) for these tasks, which microprocessors lack without
additional components.

4. Ease of Use: MCUs are easier to set up for small, dedicated tasks since they do
not require an external memory or peripheral interface.

11
12 CHAPTER 2. MICROCONTROLLERS

2.1.3 Why Not Just Use a Microprocessor?


• External Dependencies: An MPU needs external RAM, ROM, and peripherals,
making the system more complex to design, build, and debug.

• Higher Power Consumption: MPUs consume more power and are not ideal for
portable or low-power applications.

• Overkill for Simple Tasks: Using a microprocessor for simple tasks like blinking
an LED or reading a sensor is like using a bulldozer to plant a flower—unnecessary
and inefficient.

2.1.4 When to Use a Microprocessor


Microprocessors are better suited for complex tasks requiring high computational power,
such as:

• Running operating systems

• Performing heavy data processing

• Multitasking complex applications

2.1.5 Conclusion
We use microcontrollers in embedded systems because they are cost-effective, com-
pact, energy-efficient, and tailored for specific tasks. In contrast, microprocessors are
better suited for general-purpose, high-performance computing.

2.2 Introduction to Microcontrollers


A microcontroller is an integrated circuit designed for specific tasks by combining a
processor, memory, and input/output peripherals on a single chip. It is commonly used
in embedded systems for real-time applications.

2.3 Case Study: ESP32


Overview
The ESP32 is a powerful, low-cost microcontroller developed by Espressif Systems. It
is widely used in IoT and wireless applications due to its integrated Wi-Fi and Bluetooth
capabilities.
2.4. CASE STUDY: ARDUINO 13

Technical Specifications
Feature Details
Processor Dual-core Xtensa LX6, 240 MHz
Voltage 3.3V
Flash Memory 4 MB (varies by model)
RAM 520 KB SRAM
Wi-Fi 802.11 b/g/n
Bluetooth v4.2 BR/EDR + BLE
GPIO Pins 34 (with ADC, PWM, SPI, I2C, etc.)

Variants in the ESP32 Family


Variant Flash Memory Additional Features
ESP32-WROOM 4 MB Standard module
ESP32-S2 4 MB Single-core, USB support
ESP32-C3 4 MB RISC-V core, low power
ESP32-S3 16 MB AI acceleration, USB OTG

Operating System on ESP32


• Default OS: FreeRTOS, pre-installed as part of the ESP-IDF SDK.

• Other OS Options:

– MicroPython: Python-based scripting.


– Zephyr OS: Open-source RTOS for IoT.
– Amazon FreeRTOS: AWS integration for cloud IoT solutions.

2.4 Case Study: Arduino


Overview
Arduino is an open-source hardware and software platform designed for beginners and
hobbyists. It offers a variety of microcontroller boards with an easy-to-use IDE.

Technical Specifications (Arduino Uno as Example)


Feature Details
Processor ATmega328P, 16 MHz
Voltage 5V (operates on 5V and 3.3V)
Flash Memory 32 KB
RAM 2 KB SRAM
EEPROM 1 KB
GPIO Pins 14 (6 PWM, 6 analog)
14 CHAPTER 2. MICROCONTROLLERS

Variants in the Arduino Family


Variant Processor Voltage Flash Memory Special Features
Arduino Uno ATmega328P 5V 32 KB Basic development board
Arduino Mega ATmega2560 5V 256 KB More I/O pins (54 digital)
Arduino Nano ATmega328P 5V 32 KB Compact form factor
Arduino Due SAM3X8E (ARM) 3.3V 512 KB 32-bit processor

Operating System on Arduino


• Default: No operating system (bare-metal programming).

• Optional RTOS:

– FreeRTOS: Adds multitasking capabilities.

– ChibiOS: A lightweight RTOS with Arduino support.

2.5 Case Study: Particle Photon


Overview
The Particle Photon is a Wi-Fi-enabled microcontroller optimized for IoT applications.
It is part of the Particle ecosystem, which provides seamless cloud integration and a
beginner-friendly environment.

Technical Specifications
Feature Details
Processor ARM Cortex-M3, 120 MHz
Voltage 3.3V
Flash Memory 1 MB
RAM 128 KB SRAM
Wi-Fi 802.11 b/g/n (Broadcom chipset)
GPIO Pins 18
Cloud Integration Full Particle Cloud support

Operating System on Photon


• Runs on Particle Device OS, a lightweight RTOS for IoT applications.

• Provides built-in cloud functionality for remote monitoring and firmware updates.
2.6. COMPARISON: ESP32 VS ARDUINO VS PHOTON 15

2.6 Comparison: ESP32 vs Arduino vs Photon


Feature ESP32 Arduino Uno Photon
Processor Dual-core Xtensa LX6, 240 MHz ATmega328P, 16 MHz ARM Cortex-M3, 120 M
Voltage 3.3V 5V 3.3V
Flash Memory 4 MB 32 KB 1 MB
RAM 520 KB 2 KB 128 KB
Connectivity Wi-Fi, Bluetooth None Wi-Fi
GPIO Pins 34 14 18
Cloud Support Limited (via libraries) None Full Particle Cloud
Ease of Use Moderate Beginner-friendly Beginner-friendly

2.7 Conclusion
• ESP32: Ideal for high-performance IoT and wireless applications.

• Arduino: Best for beginners and simple projects.

• Photon: Optimized for cloud-connected IoT applications.

• Choose based on application complexity, connectivity, and processing power needs.

2.8 Purpose of SRAM vs Flash Memory on ESP32


1. SRAM (Static Random-Access Memory)
• Purpose: Temporary storage for data and variables during program execution.

• Key Characteristics:

– Volatile: Data is lost when the power is turned off.


– Fast read and write operations, essential for real-time tasks.
– Used for storing:
∗ Runtime variables (e.g., counters, flags).
∗ Function call stacks.
∗ Buffers for data transmission or sensor input (e.g., Wi-Fi, UART).

• Example Use Cases:

– Storing intermediate data while processing sensor readings.


– Holding packet data during network communication.

2. Flash Memory
• Purpose: Permanent storage for the program code and static data.

• Key Characteristics:

– Non-volatile: Retains data even when power is off.


16 CHAPTER 2. MICROCONTROLLERS

– Slower than SRAM but provides much larger storage capacity.


– Used for storing:
∗ Firmware (compiled code).
∗ Configuration files or static assets (e.g., images, HTML for web servers).
∗ Non-volatile user data (e.g., Wi-Fi credentials, calibration data).

• Example Use Cases:

– Storing the main firmware and libraries for the ESP32.


– Saving web server files or sensor calibration data for future use.

Comparison of SRAM and Flash Memory on ESP32


Feature SRAM Flash Memory
Type Volatile Non-volatile
Purpose Temporary data during execution Permanent storage for firmware and data
Speed Faster Slower
Capacity Limited (e.g., 520 KB on ESP32) Larger (e.g., 4 MB or more)
Data Retention Lost when powered off Retains data after power-off
Examples Variables, buffers, function stacks Firmware, configuration, static files

Why Both Are Needed


• SRAM: Ensures fast, real-time operations by holding runtime data.

• Flash: Provides a large, reliable storage area for program code and persistent data.

Together, SRAM and Flash memory enable the ESP32 to function efficiently in a
wide variety of applications, from running real-time tasks to storing IoT configurations
and firmware.
Chapter 3

Compilation Flow: From Sketch to


Board

The compilation and upload process in the Arduino ecosystem transforms your sketch
(code) written in the Arduino IDE into machine code that runs on the microcontroller.
Below is the step-by-step explanation of the process:

3.1 Writing the Sketch


A sketch is the program you write in the Arduino IDE, typically using a simplified
version of C/C++. It consists of:
• setup() – Initializes settings and runs once.
• loop() – Repeats continuously after setup().

3.2 Preprocessing
When you click Verify or Upload:
1. The IDE adds necessary includes like #include <Arduino.h>.
2. Combines multiple files (if any) into one.
3. Processes macros such as #define.

3.3 Compilation
The preprocessed sketch is compiled into machine code:
• C++ Conversion: The sketch is converted into a .cpp file.
• Compiler Invocation: The IDE uses the GCC toolchain to compile the code:
– AVR GCC for Arduino Uno or Mega.
– Xtensa GCC for ESP32.
– ARM GCC for ARM-based boards.
• Linking: Combines the compiled files into an executable binary.

17
18 CHAPTER 3. COMPILATION FLOW: FROM SKETCH TO BOARD

3.4 Generating the Binary


The compiler produces a binary file (e.g., .hex or .bin) for the microcontroller.

3.5 Uploading to the Board


The binary is uploaded via:

1. Opening a serial connection.

2. Sending a reset signal to enter bootloader mode.

3. Transferring the binary using a protocol like avrdude (AVR) or esptool.py (ESP32).

3.6 Program Execution


Once uploaded:

• The microcontroller executes the bootloader.

• Runs setup() once.

• Continuously loops through loop().

3.7 Flow Summary


The following steps summarize the compilation process:

Sketch (.ino)

Preprocessing

C++ Code (.cpp)

Compilation

Binary File (.hex/.bin)

Upload to Microcontroller

Execution

This flow ensures the Arduino board executes your intended program efficiently.

3.8 Native vs Cross-Compilation


Compilation can be broadly categorized into two types: native compilation and cross-
compilation. The choice depends on the target platform for the compiled program.
3.8. NATIVE VS CROSS-COMPILATION 19

3.8.1 Native Compilation


Native compilation refers to compiling code on the same platform where the program will
eventually run.

Features:
1. The compiler and the target system architecture are the same.
2. The program can be directly executed after compilation.
3. No additional tools or configurations are needed for cross-platform compatibility.

Examples:
1. Compiling a program on an Intel processor based machine with x86-64 ISA for
execution on an Intel machine with the same ISA.

3.8.2 Cross-Compilation
Cross-compilation involves compiling code on one platform to run on a different platform
(the target).

Features:
1. The compiler generates machine code suitable for a target platform different from
the host.
2. Requires a toolchain (cross-compiler) specific to the target architecture.
3. Used in embedded systems, IoT devices, and other cases where the target has
limited resources.

Examples:
1. Compiling Arduino sketches on a computer and uploading them to an Arduino
board (host: PC, target: microcontroller).
2. Cross-compiling for ARM-based systems (e.g., Raspberry Pi) on an x86 desktop.

3.8.3 Comparison
Aspect Native Compila- Cross-Compilation
tion
Definition Compilation for the Compilation for a dif-
same platform ferent platform
Compiler Native compiler Cross-compiler
Target System Same as the host Different from the
host
Ease of Setup Easy, minimal config- Requires toolchains
uration and setup
Use Cases Local application de- Embedded systems,
velopment IoT, and cross-
platform projects
20 CHAPTER 3. COMPILATION FLOW: FROM SKETCH TO BOARD

3.8.4 Relevance to Arduino


The Arduino development process is an example of cross-compilation:
1. Sketches are written and compiled on a PC or laptop.
2. The compiled binary is uploaded to a microcontroller (the target platform).
This allows developers to use a powerful development environment to program devices
with limited resources.
Chapter 4

FreeRTOS in Compiled ESP32


Binaries

4.1 Introduction
The ESP32 is a highly versatile microcontroller, widely used in embedded systems and
IoT applications. One of its key strengths is its integration with FreeRTOS, a real-time
operating system (RTOS) that provides multitasking and system management capabili-
ties. This chapter explores the role of FreeRTOS in ESP32 development, its inclusion in
compiled binaries, and the benefits it offers for embedded applications.

4.2 Why FreeRTOS Is Included in Compiled Bina-


ries
1. FreeRTOS as Part of the ESP32 SDK
The default development frameworks for the ESP32, such as:
• ESP-IDF (Espressif IoT Development Framework)
• Arduino Core for ESP32
use FreeRTOS as their underlying operating system. It provides essential services such
as task scheduling, timers, and inter-task communication.

2. Automatic Inclusion of FreeRTOS


When you compile a program for the ESP32, the compiled binary automatically includes:
• Your application code, such as the setup() and loop() functions or FreeRTOS
tasks.
• FreeRTOS kernel, which handles multitasking and resource management.
• ESP32-specific drivers and libraries, such as the Wi-Fi and Bluetooth stacks.
• Any external libraries used in your program.
This seamless integration simplifies the development of complex applications.

21
22 CHAPTER 4. FREERTOS IN COMPILED ESP32 BINARIES

4.3 Components Included in the Binary


The compiled binary typically includes:
Component Description
Application Code User-written functions like setup() and loop().
FreeRTOS Kernel Task scheduler, memory management, and synchronization primitives.
Hardware Abstraction Layer Drivers for GPIO, UART, SPI, I2C, etc.
ESP32-Specific Libraries Wi-Fi stack, Bluetooth stack, and system services.
External Libraries Any additional libraries included in the program.

4.4 Bare-Metal Programming vs FreeRTOS


Although it is possible to program the ESP32 without FreeRTOS (bare-metal program-
ming), this approach requires:

• Direct management of hardware resources.

• Handling interrupts and timers manually.

• Custom implementations of multitasking and synchronization.

In contrast, FreeRTOS simplifies these tasks by providing a robust, pre-built framework.

4.5 How to Confirm FreeRTOS in Your Binary


1. Build Logs (ESP-IDF)
If using ESP-IDF, the build process will show the inclusion of FreeRTOS-related files,
such as:

freertos/port.c
freertos/queue.c

2. Runtime Task List


FreeRTOS provides a function, vTaskList(), which prints all running tasks, including
system tasks, allowing you to confirm that FreeRTOS is managing the program.

4.6 Advantages of Including FreeRTOS


• Multitasking: Allows multiple tasks to run concurrently, improving efficiency.

• Real-Time Scheduling: Ensures tasks are executed within precise time con-
straints.

• Simplified Resource Management: Provides APIs for memory, synchroniza-


tion, and task communication.

• System-Level Features: Manages system tasks like Wi-Fi, Bluetooth, and low-
power modes seamlessly.
4.7. CONCLUSION 23

4.7 Conclusion
The inclusion of FreeRTOS in ESP32 binaries is crucial for leveraging the full potential
of the microcontroller. It simplifies the development of real-time, multitasking appli-
cations, enabling developers to focus on application logic rather than low-level system
management.
24 CHAPTER 4. FREERTOS IN COMPILED ESP32 BINARIES
Chapter 5

PCBs

5.1 PCB Design with Microcontrollers: Why and


When?
Why Move to PCB Design?
• Prototyping Completes Successfully: Once a circuit works as expected on a
breadboard, moving to a PCB ensures reliability and scalability.

• Compact and Durable Systems: PCBs are more compact, durable, and profes-
sional compared to fragile breadboard setups.

• Improved Signal Integrity: PCBs reduce noise, interference, and loose connec-
tions, which are critical in sensitive or high-speed circuits.

• Mass Production: PCBs enable uniform and efficient manufacturing for large-
scale production.

• Complex Circuits: Managing many components on a breadboard becomes im-


practical; PCBs organize and simplify connections.

• Power and Heat Management: PCBs provide efficient power distribution and
allow for heat dissipation through thermal vias or heat sinks.

• Custom Enclosure Fit: PCBs can be designed to fit specific mechanical enclo-
sures, improving aesthetics and functionality.

• Long-Term Reliability: PCBs are less prone to wear and tear, simplifying main-
tenance and troubleshooting with labeled traces.

ESP32-WROOM: A PCB Module


• The ESP32-WROOM is a small, pre-manufactured PCB module containing:

– ESP32 microcontroller
– Flash memory, antenna, crystal oscillator, and power regulation circuitry

• It simplifies using the ESP32 by providing solder pads or pin headers for easy
integration.

25
26 CHAPTER 5. PCBS

Why Design a Custom PCB for ESP32-WROOM?


Even though ESP32-WROOM is a PCB module, designing a custom PCB may be nec-
essary for:

• Custom Circuit Integration: Adding sensors, actuators, or power circuits.

• Connector and Pin Optimization: Arranging pins to match specific application


needs.

• Power Management: Designing custom power supply or battery management


circuits.

• Mechanical Fit: Ensuring proper fit within an enclosure.

• Simplified Deployment: Making mass production easier and more professional.

PCB-on-PCB: ESP32-WROOM on Custom PCB


• Using the ESP32-WROOM on a custom PCB effectively means placing a PCB on
top of another PCB.

• This modular approach:

– Simplifies development by abstracting complex microcontroller circuitry.


– Saves space and reduces design complexity.
– Enables modular upgrades or replacements.

Conclusion
Transitioning to PCB design from microcontroller modules like ESP32-WROOM ensures
reliability, scalability, and a professional finish, especially in complex or mass-production
applications.
Chapter 6

SoCs vs MCUs

6.1 Can a Microcontroller Be Considered an SoC?


What Is an SoC?
• A System on Chip (SoC) integrates a CPU, memory, peripherals, and other
components required for a specific application onto a single chip.

• Designed to provide a complete system in a compact form factor.

Microcontroller Characteristics
• A microcontroller typically includes:

– CPU: For processing tasks.


– RAM: For temporary data storage.
– Flash memory or ROM: For program storage.
– Peripherals: Timers, I/O ports, ADC, UART, SPI, I2C, etc.

• Designed for embedded systems to perform specific tasks efficiently.

Why Microcontrollers Qualify as SoCs


• Like an SoC, a microcontroller integrates most of the components needed for a
system to function onto a single chip.

• Example microcontrollers:

– ESP32: Includes CPU, RAM, flash memory, Wi-Fi, and Bluetooth.


– STM32: Combines a Cortex-M CPU, RAM, flash, and various peripherals.

Key Differences Between Microcontrollers and SoCs


• Purpose and Complexity:

– Microcontrollers: Optimized for simpler, specific tasks (e.g., sensor control


or motor management).

27
28 CHAPTER 6. SOCS VS MCUS

– SoCs: More powerful, capable of running operating systems like Linux, used
in complex systems (e.g., smartphones, IoT hubs).

• Peripheral Integration:

– SoCs often include high-performance peripherals (e.g., GPUs, DSPs, wireless


modules like 5G).
– Microcontrollers have fewer peripherals and prioritize power efficiency.

Examples
• Microcontroller as SoC:

– ESP32: Dual-core processor, RAM, flash, Wi-Fi, and Bluetooth in one chip.
– STM32F4: Cortex-M CPU, RAM, flash, and peripherals.

• Traditional SoC:

– Raspberry Pi 4 SoC (Broadcom BCM2711): Quad-core Cortex-A72,


GPU, RAM (external), and high-speed peripherals.

Conclusion
• A microcontroller can be considered a basic form of SoC because it integrates
most system components onto a single chip.

• However, SoCs generally refer to more powerful and feature-rich chips used in
advanced systems, while microcontrollers are optimized for simpler, low-power
applications.

You might also like