Connectivity Architecture

Introduction

Connectivity architecture describes how your embedded device exchanges data with the outside world: over Wi-Fi or Ethernet, through a radio module on UART/SPI, or via a local link to a host PC. Not every project needs a network — a datalogger on an SD card has no connectivity layer. But if your device posts sensor readings to a server or accepts remote commands, you need a deliberate plan for who initiates connections, which protocol you use, and what happens when the link fails.

Second-year projects often jump straight to copy-pasted example code from one specific board. Connectivity architecture means choosing patterns that fit your requirements, configuring networks without hardcoded passwords, and designing APIs you can test independently of the sensor hardware.

This article covers common communication patterns, network provisioning, and protocol design for network-capable microcontrollers. Read Hardware architecture for buses on the board and Firmware architecture for where communication code lives in your program.

Do you need connectivity?

Ask before adding a radio or network stack:

Adding connectivity increases power use, code size, and debug surface. Build and test physical + firmware layers first, then add the network module.

Common communication patterns

Many connected prototypes combine patterns: telemetry as a client plus a small HTTP server for local configuration.

Network provisioning

Hardcoding ssid and password in source code fails the moment you change location or pass the device to a teammate.

Run network setup during initialization — before HTTP or MQTT clients that need an active connection. Store credentials in non-volatile memory (flash, EEPROM, or board-specific storage) so they survive reboot.

On Wi-Fi-capable boards, captive portal provisioning (temporary access point + configuration web page) is a common pattern. Your SDK or vendor examples may provide a library for this; otherwise implement credential storage in non-volatile memory yourself.

HTTP and REST

HTTP is common when a device talks to a web backend.

Outbound (device as client)

The exact API depends on your stack (BSD sockets, mbed TLS, vendor Wi-Fi SDK, lwIP, etc.). In general:

• Plain HTTP for early development on trusted networks
• HTTPS/TLS for production or untrusted networks

Send structured payloads (usually JSON):

1
2
3
4
5

POST /api/readings HTTP/1.1
Host: example.com
Content-Type: application/json

{"temperature": 22.5, "humidity": 48}

Inbound (device as server)

A lightweight HTTP server on the MCU lets a backend or browser send commands or read status. Capabilities vary by board and library — check what your stack supports for TLS on the server side.

IP addresses change

DHCP assigns a new address on each network. Options:

• Store the device IP in your backend when it first checks in
• Use mDNS (e.g. mydevice.local) on friendly networks
• Reserve a fixed DHCP lease on your router for demos

Document how your system discovers the device after a network change.

MQTT and other protocols

MQTT suits many-to-many IoT: devices publish to topics; subscribers react without direct IP coupling. Full explanation, videos, and lab links: MQTT and IoT messaging.

For radio choice (Wi-Fi vs BLE vs LoRa), see Wireless for embedded. For dashboards and glue logic on a Pi, see Node-RED for IoT.

UART or SPI to a radio module (LoRa, GSM, Zigbee coordinator) is another path — the architecture is the same: a communication module in firmware, a protocol agreed with the remote end, and timeouts when the link is down.

CAN bus (common in automotive and industrial MCUs) connects nodes on a shared bus without TCP/IP. The same layering applies: driver, protocol, application logic.

Protocol and API design

Define contracts early — on paper or in a shared doc:

• Endpoints or topics — what path or topic carries which data?
• Payload format — JSON fields, units, timestamp time zone
• Direction — who sends commands? who acknowledges?
• Failure behaviour — retry interval, queue size, safe actuator state when offline
• Security — TLS on untrusted networks; API keys or tokens where required

Test the API with curl or Postman from your laptop before assuming the firmware is at fault.

Where connectivity lives in firmware

Follow Firmware architecture:

• Communication module — connect, send, receive, parse; no direct actuator calls inside protocol handlers
• Application logic — decides what to send and how to react to commands
• Non-blocking — do not stall sensor reading inside long network waits; use timeouts

Relevant topics

• Embedded system architecture
• Firmware architecture
• MQTT and IoT messaging
• Node-RED for IoT
• Docker for edge and IoT
• Wireless for embedded
• Documenting your design
• Knowledge overview

Starting points

1. Draw a message diagram — arrows from device to server and back; label payloads.
2. Prove network join with a minimal program (connect, print address) before higher-level protocols.
3. Use provisioning (captive portal, serial config, etc.) so you are not recompiling for every network.
4. Send one fake JSON value to your API before reading real sensors.
5. Test the server path with curl from your laptop to the device's address.
6. Define offline behaviour in one sentence (e.g. "LED blinks slow red when disconnected").

Focus points

• Connectivity is optional — add it only when requirements need remote data or control.
• Provision networks properly — no plaintext SSID/password in Git.
• IP addresses are not permanent — document discovery or registration.
• Separate protocol code from sensor code — easier to test each side.
• Timeouts everywhere — hung connections should not freeze the device.
• Security matches context — TLS on public networks; lab HTTP may be acceptable locally.
• Match stack to MCU — libraries and TLS support differ per board; read the docs for yours.

Key points

• Connectivity architecture chooses how the device talks to other systems: client, server, pub/sub, bus, or local.
• Network provisioning belongs in startup, before application protocols.
• HTTP and MQTT are common in connected projects — define endpoints, topics, and payloads explicitly.
• Plan for changing addresses and network failure.
• Keep communication in its own firmware module with clear boundaries to sensor and actuator code.