skip to content

Raspberry Pi

The Raspberry Pi is the standard cheap ARM board for embedded and maker work, running Raspberry Pi OS with GPIO and peripheral buses exposed. Interviews use it as the concrete setting for questions about embedded Linux and talking to hardware.

on this pageshow

questions

6

Why can't you wire a 5 V sensor output straight to a Raspberry Pi GPIO pin, and what do you put in between?

level: juniorimportance: must knowfreq 55%

answer

  1. the header's 5 V pin is not GPIO
  2. 3.3 V bank, no tolerance headroom
  3. protection diodes conduct into the rail
  4. divider or translator, opto if isolated
  5. no ADC anywhere on the board

basics

~20 s

Raspberry Pi GPIO pins run 3.3 V logic and are not 5 V tolerant, so 5 V on an input can damage the pin or the SoC. Put a level shifter or a resistor divider in between.

solid answer

~50 s

The 40-pin header does carry 5 V (on pins 2 and 4), but that is a power rail — the GPIO lines themselves are part of a 3.3 V I/O bank and are **not 5 V tolerant**. Feeding a 5 V logic output into a GPIO input pushes current through the pin's ESD protection into the 3.3 V rail; that can kill the pin outright, or worse, degrade it silently and disturb the rail so the board misbehaves in ways that look like software bugs. For a slow signal a 1 kΩ/2 kΩ resistor divider is enough; for anything fast or bidirectional use a proper level-translator IC, and an opto-isolator when the two sides don't share a clean ground. The reverse direction matters too: 3.3 V out may not clear a 5 V part's high-level input threshold, and a pin can only source on the order of 16 mA, so real loads need a transistor or MOSFET.

go deeper

for a junior

Say plainly that GPIO is 3.3 V logic and not 5 V tolerant, that the 5 V header pins are power only, and that you would use a level shifter or a resistor divider before connecting a 5 V signal.

for a middle

Explain the mechanism: overvoltage forward-biases the pin's protection diode into the 3.3 V rail, so damage may be gradual and show up as flaky board behaviour rather than a dead pin. Know the per-pin current budget and when a transistor is required.

for a senior

Show you design for the failure you cannot see: choose translation versus isolation based on ground integrity and noise, budget total GPIO current, and recognise mystery reboots or SD corruption as a possible symptom of current being injected into the rail.

for a principal

Own the tradeoff between a discrete divider that is free and a translator or isolator that is qualified: signal speed, ground offsets, field-serviceability and safety approvals usually decide it, not component cost. Set the rule that anything mains-adjacent is isolated by policy.

## What the header actually provides The 40-pin header carries three kinds of pin: power, ground, and GPIO. There is a 5 V supply (pins 2 and 4) and a 3.3 V supply (pins 1 and 17), plus several grounds. The 5 V pins come straight off the board's input supply and exist to *power* peripherals. The GPIO lines are something else entirely: they belong to an I/O bank inside the SoC that is powered from the 3.3 V rail. A GPIO driven high outputs roughly 3.3 V, and a GPIO configured as an input expects a voltage somewhere between 0 V and 3.3 V. Nothing on the board translates between those two worlds for you. ## Why 5 V is not merely "a bit high" Some microcontrollers advertise *5 V tolerant* inputs, meaning the input structure is designed to survive a voltage above its own supply. Raspberry Pi GPIO is not in that category. Every pin has protection diodes to the supply rails. When you apply 5 V to a 3.3 V pin, the upper diode becomes forward-biased and starts conducting current from your sensor into the 3.3 V rail. The only thing limiting that current is the source's own drive strength, which is usually far more than the diode is meant to carry. There are two failure shapes, and the second is the one that wastes days. The obvious one is a dead pin: it stops responding, or reads stuck-high forever. The insidious one is partial — the injected current lifts the 3.3 V rail slightly, which upsets other peripherals, the SD card interface, or the USB ports. The symptom is a board that reboots or corrupts data "randomly", and nobody suspects the temperature sensor. Damage is also cumulative: a pin can survive the abuse for weeks and then fail. ## Making a 5 V output safe to read From cheapest to most correct: - **Resistor divider.** Two resistors from the 5 V signal to ground, tapped in the middle. With 1 kΩ on top and 2 kΩ on the bottom you get 5 × 2/3 ≈ 3.3 V. It costs two parts and works fine for slow signals like a switch or a low-rate serial line. It is unsuitable for fast edges, because the divider's impedance and the cable capacitance form a low-pass filter that rounds the signal off. - **Level-translator IC.** A dedicated part with a low-voltage side and a high-voltage side. This is what you want for SPI, fast UART, or anything bidirectional. For open-drain buses such as I²C the standard answer is a small MOSFET-based bidirectional shifter. - **Opto-isolator.** When the other side is electrically noisy, mains-adjacent, or on a different ground reference, isolate rather than translate. You give up speed and gain safety. One shortcut worth knowing: a device whose output is *open-drain* never drives high at all — it only pulls low and lets a pull-up resistor set the high level. Pull it up to 3.3 V and it is already Pi-safe. This is why many I²C parts labelled "5 V" interoperate with no shifter. Confirm the device's high-level input threshold before relying on it, because a 5 V-powered part often wants at least 0.7 × 5 V ≈ 3.5 V to read a high, which 3.3 V does not reach. ## The output direction, and current Driving *out* of the Pi has two separate constraints. The first is voltage: 3.3 V may sit below the receiving part's high-level threshold, giving you a link that works on the bench and fails when it warms up. The second is current. A Raspberry Pi GPIO is documented with a per-pin maximum on the order of 16 mA (with a lower default drive strength) and a recommended total across all pins around 50 mA. An indicator LED with a series resistor is fine. A relay coil, a motor, or an LED strip is not: use a transistor or logic-level MOSFET, power the load from its own supply, and tie the grounds together. ## There are no analog inputs A related trap in the same interview: no Raspberry Pi model has an analog-to-digital converter on the GPIO header. A GPIO can only tell you "above threshold" or "below threshold". Reading a potentiometer, a thermistor, or any analog sensor needs an external ADC on SPI or I²C — the MCP3008 is the classic hobby choice — or a sensor that already speaks a digital protocol. Candidates who claim they will "read the voltage on a GPIO pin" have not actually built anything on the platform. ```python # Correct: a digital sensor on a digital pin, powered from 3V3 from gpiozero import Button button = Button(17) # BCM GPIO17, internal pull-up button.wait_for_press() ```

  • Your sensor is analog — a thermistor on a voltage divider. How do you read it on a Pi?
    You can't read it directly: no Raspberry Pi model has an ADC on the GPIO header, and a GPIO only reports above or below a threshold. Add an external ADC over SPI or I²C (an MCP3008 is the common choice), or pick a sensor that outputs a digital protocol such as I²C or 1-Wire. The RC charge-time trick works but is imprecise and drifts with temperature.
  • You need to switch a 12 V solenoid from a GPIO. Walk me through the circuit.
    Never from the pin itself — it can source roughly 16 mA and the coil wants amps. Drive the gate of a logic-level N-channel MOSFET (or a transistor with a base resistor) from the GPIO, put the solenoid between 12 V and the drain, and tie the 12 V supply's ground to the Pi's ground. Add a flyback diode across the coil, or the inductive kick will destroy the switch.
  • Why might a 5 V I²C sensor work fine with no level shifter?
    I²C is an open-drain bus: devices only pull the line low and a pull-up resistor establishes the high level. If the pull-ups go to 3.3 V, nothing ever drives 5 V onto the Pi's pins. The remaining risk is in the other direction — a 5 V-powered part may need roughly 3.5 V to register a high, so verify its input threshold rather than assuming it.

saying these in an interview costs you the question

  • The header has 5 V pins, so GPIO is 5 V tolerant
  • A resistor in series makes any voltage safe
  • You can read a sensor's analog voltage on a GPIO pin
  • Drive the relay coil straight from the pin, it's only 12 V
  • A diode drop takes 5 V down to logic level

context

open as a page

Raspberry Pis deployed as always-on devices frequently end up with a corrupted or worn-out microSD card. Why does that happen, and how would you design a deployment to avoid it?

level: seniorimportance: must knowfreq 62%

basics

~20 s

Consumer microSD cards have limited write endurance and simple controllers, so constant small writes from logs, databases and swap wear them out, while power loss mid-write can corrupt the card's internal mapping. Cut the write rate, or move the root filesystem off the card entirely.

open as a page

A Raspberry Pi running a camera and a USB disk reboots at random and the disk keeps dropping out, with nothing in the application logs. How do you check whether power is the cause?

level: middleimportance: should knowfreq 52%

basics

~20 s

Read the firmware's throttle flags with vcgencmd get_throttled and check the kernel log for under-voltage messages. The bitmask separates a current problem from one that has occurred since boot, and distinguishes low voltage from thermal throttling.

open as a page

On a current Raspberry Pi OS release, how does a userspace program obtain a GPIO line, and why is the older /sys/class/gpio interface discouraged?

level: middleimportance: should knowfreq 45%

basics

~20 s

Linux now exposes GPIO as character devices at /dev/gpiochipN, and a program requests specific lines through ioctls, usually via libgpiod. The kernel releases a line when the requesting file descriptor closes. The older /sys/class/gpio export interface is deprecated and leaves lines stranded.

open as a page

When would you argue against shipping a product on a consumer Raspberry Pi board, and what would you move to instead?

level: principalimportance: should knowfreq 34%

basics

~20 s

Argue against it when the environment, timing or reliability requirements exceed a consumer board: wide ambient temperature range, hard real-time deadlines, uncorrected memory errors, or a mechanical socket that must survive vibration. Move to a Compute Module with eMMC, an industrial SBC, or a microcontroller.

open as a page

How does a Raspberry Pi's boot sequence differ from a PC that starts at BIOS/UEFI and hands off to a bootloader?

level: middleimportance: nice to knowfreq 38%

basics

~20 s

A Raspberry Pi has no BIOS/UEFI and normally no GRUB. Firmware on the board's VideoCore side starts first, reads config.txt from a FAT partition, loads the kernel and a device tree, then releases the ARM cores. Configuration is text files, not an interactive firmware menu.

open as a page