Getting things talking is the fifth step of building the embedded subsystem. As soon as several components have to exchange data — between chips on the same board, or with the outside world (a PC, a network, an operator) — you have to choose how they talk to each other: a wired bus on the inside, a wireless or cabled link towards the outside. The deliverable is a choice of communication technologies, justified and tested.
This step is optional: the client’s need is what decides. Read the functional requirements specification again, along with the functions from the scoping stage: if none of them calls for talking to anything — remote control, monitoring, sending measurements, working alongside another system — you can skip this page and go straight to step 6. A subsystem built around a single microcontroller, with every sensor and actuator wired directly to it (I/O, analog inputs, PWM signals), often has neither an internal bus to choose nor an external link to create. The stocktaking of step 1 settles it: if it turns up no exchange between chips and no need for an external link, this step shrinks to almost nothing.
The right mindset
The temptation is to add communication because it happens to be there: a bus because the board has one, Wi-Fi because the chip offers it. Every link has a cost, though — wires, code, power draw, things that can fail. Only keep a bus or a link if a real exchange calls for it, and choose it on concrete criteria: how many devices, what data rate, what distance, which direction. The simplest thing that does the job is the right one.
Goal of this step
Produce a justified communication choice that:
- lists every exchange needed, internal and external;
- settles, for the exchanges between chips, on the right bus (or on none at all, if everything is wired directly);
- settles, for the link to the outside, on a suitable wired or wireless link;
- has been tested on at least one link, end to end.
Method
1. List the exchanges
Before choosing a technology, write down who has to talk to whom. Tell the internal exchanges (between the board and a peripheral chip: a sensor on a bus, a display, a memory) apart from the external ones (to a PC, a phone, another system, a network). For each of them, note the data exchanged, the data rate needed, the distance and how many devices take part. This map of the exchanges is what will tell you which buses and which link you actually need, and often that you need fewer than you thought.
Example: 3-axis arm project
Stocktaking of the arm’s exchanges: the three angle sensors are analog (read directly by the converter, no bus), the three drivers receive PWM and logic signals directly, the limit switches are logic inputs. No exchange between chips at all, so there is no internal bus to choose. One exchange is left: receiving the operator’s commands and sending the status back.
Output: zero internal buses, one external link (the operator). For this project the step comes down to that single link, a direct illustration of how optional buses are.
Deliverable 1/3 — Map of the exchanges
- The list of internal and external exchanges, with data, data rate, distance and number of devices
2. Choose the internal buses
For each exchange between chips, choose the bus against the criteria you listed. I²C links several components with two wires at a moderate data rate, ideal for a few sensors and a display. SPI is faster but wants more wires, for a memory or a demanding screen. UART is a plain point-to-point serial link. The communication buses page covers how they work and where they stop. Often the bus is in fact forced on you by the component you settled on when choosing the hardware: a sensor sold as I²C gets wired as I²C. Your choice then comes down to checking compatibility and organising how the bus is shared. If there is no exchange between chips, this step is empty. That is a valid result, not an oversight.
Watch out
Piling up buses, or picking one out of reflex, complicates the system without serving it. A bus is justified by a real exchange and by its criteria (devices, data rate, distance), not by its presence on the board. Three analog sensors read directly need no bus. A display added later will, on the other hand, go naturally onto the I²C that is already there.
Example: 3-axis arm project
The arm has no exchange between chips: no internal bus. As a counter-example, if you added a status display and a digital torque sensor, both would go onto the same I²C bus (two shared wires, plenty of data rate) rather than being wired separately.
Output: no internal bus for the arm as it stands. I²C would be the default choice if digital components were added.
Deliverable 2/3 — Internal buses chosen
- For each exchange between chips, the bus chosen and why (or an explicit “no bus needed”)
3. Choose the external link
For the link to the outside — an operator PC, a phone, a network — choose between wired and wireless. Wired (USB serial) is simple, reliable and sometimes powers the board, but it ties the system down. Wireless opens up mobility: Wi-Fi for a high data rate and an existing network, BLE for small, frugal exchanges, Zigbee for a mesh of sensors, LoRa for long range at a very low data rate. The wireless technologies page helps you weigh them up. Keep in mind that a serial console link (USB) stays useful for debugging almost whatever operator link you settle on.
To find your way, the criteria that separate them are range, data rate, power draw and the infrastructure available:
| The question to ask yourself | Typical answer |
|---|---|
| Does the system stay within cable reach while in use? | Wired (USB serial) — simple and reliable |
| Mobility or distance, comfortable data rate, a network already there? | Wi-Fi |
| Small messages to a phone, tight battery budget? | BLE |
| Many sensors to mesh across a building? | Zigbee |
| Kilometres of range, a few bytes an hour? | LoRa |
Before you freeze the choice, test the link end to end — a command one way, a status back: ten minutes that save you from finding out late that a range, a data rate or a pairing does not hold. Full qualification comes later, with the test protocol of step 6.
Tip
Wireless is tempting, but it has a cost: power draw, reliability, security. If the system stays within cable reach while in use, a wired link is often safer and simpler. Keep wireless for the cases where mobility or distance really call for it.
Example: 3-axis arm project
The operator has to be able to drive the arm from a distance, so the link chosen is Wi-Fi (built into the ESP32, with far more data rate than commands and status feedback need). Alongside it, the USB serial console stays plugged in while the firmware is being brought up, to watch what it does.
Output: an operator link over Wi-Fi, checked with a command-and-status round trip, and a serial console for debugging. That is the arm’s only real “communication”.
Deliverable 3/3 — External link chosen
- The technology chosen for the external link (wired or wireless), justified and tested end to end, and the debugging link kept alongside
Wrap-up
Your communications are settled: the exchanges are listed, the internal buses chosen (or ruled out for good reason), the external link chosen and tested. What follows is hardening the whole thing at step 6. The communication choices go into the technical design file of the V-model.
Common pitfalls
Adding communication because it happens to be there. A bus or a link is justified by a real exchange, not by its presence on the board. The simplest thing that does the job is the right one.
Reaching for wireless out of reflex. When a cable is enough for the way the system is used, wired is simpler, more reliable and often safer. Wireless earns its place through mobility or distance.
Ignoring the number of devices, the data rate and the distance. Those three criteria decide the bus. Skipping them means picking at random between I²C, SPI and UART.
Forgetting the console link. A serial debugging link stays useful during bring-up almost every time, even when the operator link is wireless.
Taking a wireless link’s robustness for granted. A radio link drops out, gets jammed, can be listened to. A system that depends on one has to plan for the link being lost and, if the data is sensitive, for protecting it.
What belongs elsewhere
Running the step belongs to the V-model. The communication choices appear in the technical design file. This page produces the artefact, the V-model puts it into the project.
Link security (encryption, integrity, authentication), as soon as the data exchanged is sensitive, is one dimension of safety and quality, arbitrated at project level.
The application protocol, the format of the commands and statuses exchanged on top of the link, belongs to the firmware and to the engineer-level material of your family.
See also
- Building the embedded subsystem
- Previous step: Programming
- Next step: Hardening and debugging
- Communication buses — UART, I²C, SPI
- Wireless technologies — Wi-Fi, BLE, Zigbee, LoRa
- Technical design file (project management, V-model)
- Safety and quality (cross-cutting)