By the end of this section, you will be able to:
Sammy the Sensor is excited! “Today we’re setting up our workshop to build cool IoT gadgets!”
Lila the Light Sensor holds up two boards: “First, we need to pick our brain! A microcontroller is like a simple calculator – it’s small, cheap, and runs on a tiny battery. A single-board computer is like a whole laptop – it can do much more, but it’s hungrier for power.”
Max the Motion Sensor points to some wires: “Then we need to connect everyone together! I use I2C – it’s like a school bus that picks up lots of sensors on the same road. SPI is like a race car – super fast but needs its own lane for each passenger. And UART is like a walkie-talkie – just two friends talking directly.”
Bella the Buzzer adds: “And don’t forget the tools! Just like a carpenter needs a workbench, a hammer, and a level, we need a code editor, a way to save our work, and a way to test it before we ship it out into the world!”
Think of it this way: Building an IoT device is like building a treehouse. You pick your materials (hardware), connect the pieces (serial protocols), and use proper tools (development environment) to make sure it won’t fall apart!
If you are new to IoT development, here is the big picture:
IoT development means writing software that runs on small computers (like an ESP32 or Raspberry Pi) which are connected to sensors and the internet. Unlike building a website or a phone app, you must also think about:
The three sub-chapters here cover these topics in order:
If you have programmed in Python or C before but never worked with embedded hardware, start with the Hardware Selection chapter. If you have used an Arduino before, you can jump ahead to Serial Protocols.
This section covers the essential development tools, hardware platforms, and workflows for building IoT systems. The content is organized into three focused chapters that progressively build your expertise from hardware selection through professional development practices.
Start with Hardware Platform Selection →
Learn to choose between microcontrollers (Arduino, ESP32) and single-board computers (Raspberry Pi) based on power requirements, cost constraints, and processing needs. Includes decision trees, power budget calculations, and platform evolution from prototype to production.
Key Topics:
Continue to Serial Communication Protocols →
Master I2C, SPI, and UART protocols for connecting sensors and peripherals. Understand when to use each protocol based on speed, pin count, distance, and device count requirements.
Key Topics:
Finish with Development Workflow and Tooling →
Establish professional development practices including IDE setup, version control workflows, CI/CD pipelines, hardware debugging, and Over-The-Air (OTA) update strategies.
Key Topics:
Understanding where hardware selection, serial protocols, and development tooling fit in the broader IoT architecture helps you make better decisions early.
Choosing the right serial protocol is one of the most common early decisions. This quick comparison helps you orient before diving into the detailed chapter.
| Feature | I2C | SPI | UART |
|---|---|---|---|
| Wires | 2 (SDA, SCL) | 4 + 1 per device | 2 (TX, RX) |
| Max Speed | 3.4 Mbps | 80+ Mbps | ~1 Mbps |
| Devices | Up to 127 on one bus | 1 per chip-select line | Point-to-point |
| Duplex | Half-duplex | Full-duplex | Full-duplex |
| Distance | ~1 m (without buffer) | ~0.3 m typical | ~15 m (RS-232 levels) |
| Best For | Sensor arrays, EEPROMs | Displays, SD cards, ADCs | GPS, Bluetooth, debug |
This worked example walks through a realistic decision process that spans all three sub-chapters.
Scenario: You are building a greenhouse monitoring system that reads temperature, humidity, soil moisture, and light levels every 30 seconds, displays readings on a small OLED screen, and transmits data over Wi-Fi to a cloud dashboard. The system is powered by mains electricity (no battery constraints). Budget is $50 per node for a 20-node deployment.
Step 1 – Hardware Selection
| Requirement | Implication |
|---|---|
| Wi-Fi connectivity | Needs built-in Wi-Fi (ESP32) or add-on module |
| 4 sensors + 1 display | At least 6 GPIO / bus connections |
| No battery constraints | Power budget is relaxed |
| $50 per node at 20 units | $1,000 total – rules out Raspberry Pi ($35+) with accessories |
| 30-second sampling | No real-time OS needed |
Decision: ESP32-WROOM-32 (~$5) – built-in Wi-Fi and Bluetooth, dual-core, plenty of GPIO, low unit cost.
Step 2 – Serial Protocol Assignment
| Peripheral | Protocol | Rationale |
|---|---|---|
| BME280 (temp/humidity) | I2C | Common I2C address, shares bus with OLED |
| Soil moisture (analog) | ADC (not serial) | Analog voltage reading on GPIO |
| BH1750 (light sensor) | I2C | Shares same I2C bus, different address |
| SSD1306 OLED display | I2C | Shares bus (address 0x3C), saves pins |
All I2C devices share the same 2-wire bus (GPIO 21 = SDA, GPIO 22 = SCL). The soil moisture sensor uses a simple analog-to-digital conversion on a separate GPIO pin. No SPI or UART needed for this project.
Step 3 – Development Workflow
| Phase | Tool / Practice |
|---|---|
| IDE | PlatformIO in VS Code with ESP32 board support |
| Version control | Git with feature branches per sensor integration |
| Testing | Unit tests for sensor reading validation; integration test with mock Wi-Fi |
| Deployment | OTA updates via ArduinoOTA library for all 20 nodes |
| Monitoring | Serial logging during development; cloud-side alerting in production |
Result: 20 nodes at ~$25 each (ESP32 + sensors + OLED + enclosure), all updatable over-the-air, streaming to a cloud dashboard via MQTT over Wi-Fi.
I2C Bus Capacitance Limit and Max Distance Calculation
You are connecting 8 sensors to an ESP32 via I2C. Each sensor PCB has 15 pF of trace capacitance, and you are using 22-gauge wire (20 pF/foot). What is the maximum wire distance before exceeding the I2C standard capacitance limit?
Given data:
Step 1: Calculate fixed capacitance
ESP32 contribution: \[C_{\text{ESP32}} = 10 \text{ pF}\]
Sensors contribution: \[C_{\text{sensors}} = 8 \times 15 = 120 \text{ pF}\]
Total fixed: \[C_{\text{fixed}} = 10 + 120 = 130 \text{ pF}\]
Step 2: Calculate remaining capacitance budget for wiring
\[C_{\text{wire budget}} = 400 - 130 = 270 \text{ pF}\]
Step 3: Calculate maximum wire length
Wire comes in two traces (SDA + SCL): \[L_{\text{max}} = \frac{270 \text{ pF}}{2 \times 20 \text{ pF/foot}} = \frac{270}{40} = 6.75 \text{ feet}\]
Result: Maximum bus length is 6.75 feet (about 2 meters) before exceeding capacitance limits. Going beyond this causes: - Signal rise time degradation (RC time constant increases) - Unreliable communication at standard 100 kHz clock - Possible need to drop to 10 kHz slow mode
Solution for longer distances:
Key insight: I2C is designed for on-board communication (inches), not long cable runs. Each connected device adds capacitance that limits max distance. Always calculate total bus capacitance when planning physical layouts.
The following diagram shows how hardware selection, protocol configuration, and tooling choices feed into the overall IoT product development lifecycle.
Avoid these frequently encountered mistakes when selecting hardware, wiring protocols, and setting up your development environment:
Choosing hardware before defining requirements: Picking an ESP32 “because everyone uses it” without checking whether you actually need its Wi-Fi, Bluetooth, or processing power. Sometimes a $2 ATmega328P is the right answer.
Ignoring I2C address conflicts: Many popular sensors (like the BME280 and BMP280) share the same default I2C address (0x76). Connecting two without changing addresses causes silent data corruption – not an error, just wrong readings.
Using SPI when I2C would suffice: SPI is faster, but each device needs its own chip-select pin. For a project with 6 slow sensors, I2C saves 10+ GPIO pins with negligible speed difference.
Skipping OTA update capability: If your devices are deployed in the field (even across a building), walking to each one with a USB cable for every firmware update becomes unsustainable fast. Plan for OTA from day one.
No version control for hardware configurations: Changing a pin assignment or I2C address in code without documenting it means the next developer (or future you) will waste hours debugging phantom wiring issues.
Testing only on the bench: IoT devices behave differently in deployment environments (temperature extremes, Wi-Fi interference, power fluctuations). Always test under realistic conditions before declaring “it works.”
Test your understanding of IoT development fundamentals before diving into the sub-chapters.
## Prerequisites
Before diving into these chapters, you should be familiar with:
Enhance your learning by exploring related resources:
Use this systematic 4-step framework to make hardware and communication decisions early:
Step 1 - Define Power Budget:
Step 2 - Calculate Processing Requirements:
Step 3 - Count Connected Peripherals:
Step 4 - Verify Cost at Scale:
Quick Reference Matrix:
| Project Type | Platform | Serial | Rationale |
|---|---|---|---|
| Battery soil sensor | ESP32 | I2C | 10 µA sleep, built-in Wi-Fi, I2C for BME280 |
| Smart thermostat | ESP32 | I2C + GPIO | Need display (I2C OLED), relay control (GPIO) |
| Security camera hub | Raspberry Pi 4 | USB + Ethernet | Face recognition needs Linux + GPU |
| Fitness tracker | nRF52840 | I2C + SPI | Ultra-low BLE power, I2C for IMU, SPI for flash |
| Industrial gateway | Raspberry Pi CM4 | Ethernet + UART | Aggregates RS-485 sensors via UART |
| Smart lighting | ESP32-C3 | GPIO + PWM | Wi-Fi control, GPIO for LEDs/relays |
This chapter introduces the three pillars of IoT development:
| Pillar | Key Decision | Impact |
|---|---|---|
| Hardware Selection | MCU vs. SBC | Determines power, cost, and capability ceiling |
| Serial Protocols | I2C vs. SPI vs. UART | Determines wiring complexity and device connectivity |
| Development Workflow | IDE, CI/CD, OTA | Determines team productivity and field maintainability |
Key takeaways:
| Direction | Chapter | Description |
|---|---|---|
| Start | Hardware Platform Selection | Choose the right MCU or SBC for your IoT application |
| Next | Serial Communication Protocols | I2C, SPI, and UART for connecting sensors and peripherals |
| Next | Development Workflow and Tooling | IDEs, CI/CD, debugging, and OTA updates |