PE1-4.3 Interfacing Displays & Sensors

Standard embedded C practice and the Arduino and NodeMCU platforms as documented by the course's own resources — written September 2026

What this is and why it exists

A board with nothing attached is not yet doing anything. This topic connects it to the world: something to look at, several things to sense with, and one thing that moves.

Each device teaches a different interface style, and that is the real content. By the end you should recognise which style a new sensor uses from its datasheet, without needing a tutorial for it.

The vocabulary

  • Serial monitor — a window on your computer showing text the board prints.
  • Current limiting — a resistor sized so an output pin is not asked for more current than it can give.
  • Library — code someone else wrote for a specific device, so you do not write it again.
  • Analog sensor — one whose output is a voltage proportional to what it measures.
  • Digital sensor — one whose output is high or low, or a sequence of pulses.
  • Time of flight — measuring distance by timing how long a pulse takes to return.
  • PIR sensor — a passive infrared sensor, which detects the heat a person radiates.
  • Driver stage — a transistor or module that switches a load the pin cannot drive itself.
  • Back electromotive force — the voltage a motor generates when its current is interrupted.

The mental model

Set up the serial monitor first and treat it as the main tool, not an afterthought. It is your only window into a running board. Printing a value at the right moment answers questions no amount of staring at code will.

The LED is the first output, and it verifies two things at once: your wiring and your upload. If it lights, the board is running your code. Current limiting is the detail that keeps the pin alive, because an LED connected directly draws more than the pin should supply.

The display is the first device with real information on it. It needs more connections and a library, and getting a static message on the screen is a genuine milestone. Making the message scroll is the next step, and it is the first time your code has to manage state across time. It is also exactly where the blocking delay problem from the previous topic bites. A scrolling message written with delays cannot do anything else while it scrolls.

Now the sensors, grouped by how they talk.

A temperature and humidity sensor typically has its own protocol, and a library reads it. What matters is recognising that a sensor may not give you a voltage at all.

Infrared and gas sensors mostly answer yes or no. They are cheap, and their limitations are worth measuring rather than reading about. Point the infrared sensor at a dark surface and at a shiny one, and you will learn more than any specification does.

A passive infrared sensor detects people by the heat they radiate. Two of its behaviours surprise people. It needs a warm-up period after power is applied before it settles. And after it triggers, it has its own re-trigger timing, so it does not report every movement separately.

The ultrasonic sensor is the first one where you compute the answer. It sends a pulse and reports how long the echo took. You multiply by the speed of sound and halve it, because the sound made the trip twice. It is really a stopwatch, and that connects the timing functions directly to a physical quantity.

The motor is where a beginner destroys a board. A microcontroller pin can supply a small current, and a motor wants far more. Connecting one directly overloads the pin. Worse, when a motor's current is interrupted its winding generates a large reverse voltage, and that voltage will damage whatever switched it. So the pin drives a transistor or a driver module instead, and that stage carries the current and clamps the reverse voltage. This is the item that stops the board dying.

What you should now be able to explain or do

Use the serial monitor as the primary debugging tool. Drive an LED with correct current limiting, and put a static and a scrolling message on a display. Say which interface style each sensor uses. Compute a distance from an ultrasonic sensor's echo time. Explain why a motor needs a driver stage and what back electromotive force does.

Check yourself

It is the only view into a running board. Without it you are guessing at what your code is doing.

Without one it draws more current than the pin should supply. The resistor limits the current and keeps the pin working.

It has to manage state over time. Written with blocking delays, nothing else in the program can run while it scrolls.

It times the echo. Multiply that time by the speed of sound and halve it, because the pulse travelled to the object and back.

It carries the current the pin cannot supply, and it handles the reverse voltage the motor generates when its current is interrupted.

Go deeper

We haven't checked most of these for screen reader use yet.

Back to Interfacing Displays & Sensors: work through the checklist