Raspberry Pi 5 Hardware: Storage, Camera, and Cooling

Summary

This chapter covers the Raspberry Pi 5's hardware capabilities beyond the Pico and Pi 500+: the PCIe interface and NVMe storage option alongside traditional microSD, USB 3.0, dual 4K display output, and Gigabit Ethernet. It covers the Camera Serial Interface and camera module properties -- resolution, frame capture, video streaming, autofocus, and global versus rolling shutter -- that later chapters build on for real-time vision. It also covers thermal management (active cooling, heat sinks, thermal throttling), power delivery over USB-C, and the 40-pin GPIO header shared with earlier Pi boards. Students finishing this chapter will be able to select appropriate storage, cooling, and camera hardware for a Pi 5 project.

Concepts Covered

This chapter covers the following 25 concepts from the learning graph:

1. PCIe Interface
2. NVMe Storage
3. MicroSD Storage
4. USB 3.0 Port
5. Dual 4K Display Output
6. Gigabit Ethernet
7. Camera Serial Interface
8. Camera Module
9. Camera Resolution
10. Frame Capture
11. Video Stream
12. Image Sensor
13. Autofocus Camera
14. Global Shutter Camera
15. Rolling Shutter Camera
16. Active Cooling
17. Heat Sink
18. Thermal Throttling
19. Power Supply Rating
20. USB C Power Delivery
21. GPIO Header
22. 40 Pin Header
23. Real Time I O
24. Kernel Driver
25. Device Tree Overlay

Prerequisites

This chapter builds on concepts from:

• Chapter 2: Choosing the Right Raspberry Pi Product
• Chapter 3: Breadboard Wiring and Electrical Fundamentals
• Chapter 11: Booting, the Desktop, and the Linux Terminal on the Pi 500+

---

A New Hardware Tier

You've already booted a Pi 500+, poked around the Linux desktop, and typed commands into a terminal. Good — because the Raspberry Pi 5 speaks that same language, just with a lot more horsepower under the hood. This chapter is a hardware tour: storage, cameras, cooling, and the connectors that make real-time AI vision possible in later chapters. Let's build something!

The Raspberry Pi 500+ you met a few chapters back is a full Linux computer built into a keyboard. The Raspberry Pi 5 is that same Linux computer philosophy, pulled out of the keyboard and given faster interfaces, more powerful cooling options, and dedicated connectors for a camera. Nothing about how you log in, open a terminal, or run Python changes. What changes is what the board can plug into, how fast it can move data, and how much heat it can generate while doing serious work like real-time video analysis. This chapter walks through those hardware differences one system at a time, so that by the time you reach the AI HAT+ in a later chapter, you already know how the Pi 5 stores its files, sees the world through a camera, and keeps itself from overheating.

A Familiar Header, More Muscle Behind It

The Raspberry Pi 5 keeps something you already recognize from the electronics fundamentals chapter: a GPIO header — General Purpose Input/Output, a row of pins that let a program directly control electrical signals rather than going through a mouse, keyboard, or screen. Specifically, it uses the same 40-pin header layout found on the Pi 500+ and, in a smaller form, the Pico: 40 physical pins in two rows, each with a defined role such as power, ground, a general-purpose digital pin, or a dedicated communication pin for protocols like I2C or SPI. Any breadboard skill or wiring habit you built in earlier chapters transfers directly — a jumper wire that worked on the Pi 500+'s header will work in the same physical position on a Pi 5.

What is different is how the Pi 5's operating system talks to whatever you plug into that header. A kernel driver is a piece of software, built into or loaded by the Linux kernel, that knows how to communicate with a specific piece of hardware and exposes that hardware's features to the rest of the operating system in a standard way. Without a driver, the operating system sees only raw electrical signals; with one, a Python program can call a simple, documented function instead of manipulating voltages directly. Many add-on boards for the Pi 5 — including the AI HAT+ you'll meet in a later chapter — need the kernel to know not just that "something is connected" but exactly which pins it uses and how to configure them. That description is supplied by a device tree overlay: a small configuration file, loaded at boot, that tells the Linux kernel which hardware is attached to the GPIO header and which driver and pin configuration to use for it, without requiring you to rebuild the entire operating system.

Berry's Key Insight

Think of a device tree overlay as a note left for the operating system: "there's a camera board on this connector — here's how to talk to it." You'll never have to write one yourself for the projects in this book, but recognizing the term matters, because it's exactly what makes plugging in a HAT and having it "just work" possible.

One more term matters before you go further, because it explains a real limitation of a Linux-based board like the Pi 5. Real-time I/O describes a system's ability to guarantee that it responds to an input within a fixed, predictable time window, every single time, with no exceptions. A microcontroller like the Pico — running no operating system at all — can offer strong real-time guarantees, which is exactly why it's the right choice for something like precisely timed motor pulses. The Pi 5 runs full Linux, a general-purpose operating system juggling dozens of background processes, so its GPIO responses are fast but not hard-guaranteed to the microsecond the way a bare-metal microcontroller's are. That tradeoff — more computing power and a full operating system, in exchange for slightly less timing precision — is a pattern you'll see again when this book compares hardware tiers.

Before looking at the header itself, it helps to see how these three ideas connect: the physical pins, the driver software that speaks to whatever is attached, and the overlay file that tells the kernel which driver to load.

Diagram: 40-Pin GPIO Header Explorer

Run the 40-Pin GPIO Header Explorer MicroSim fullscreen

40-Pin GPIO Header Explorer (interactive diagram)

Type: interactive-diagram sim-id: gpio-header-pin-explorer
Library: p5.js
Status: Specified

Learning objective: Students will identify (Bloom L1: Remember) the function of pins on the Raspberry Pi 5's 40-pin GPIO header and explain (Bloom L2: Understand) how a kernel driver and device tree overlay let the operating system recognize an attached HAT.

Canvas: 700x520px, responsive — recompute pin spacing as a fraction of height inside windowResized() so all 40 pins remain visible and legible down to 360px wide by shrinking pin circle radius before shrinking spacing.

Layout: two vertical columns of 20 pins each, matching the physical header (pin 1 top-left), drawn as small circles labeled with pin number. Color-code by function: power pins (red, 3.3V and 5V), ground pins (black), general-purpose digital pins (circuit green #2E7D32), and dedicated I2C/SPI/UART pins (indigo #3F51B5). Include a small rectangular outline labeled "HAT" hovering above the header to represent an attached add-on board.

Interaction: clicking any pin opens an infobox beneath the diagram showing the pin's number, name (e.g., "GPIO 2 / SDA"), and function in one sentence. Clicking the "HAT" rectangle plays a short two-step sequence (advance with a "Next" createButton()): step 1 highlights the pins the HAT uses in gold #D4AF37 and shows the label "Device tree overlay tells the kernel which pins are in use"; step 2 shows the label "Kernel driver lets Python talk to the HAT through those pins." A createButton() labeled "Reset" clears any open infobox and returns the sequence to step 0.

Implementation: p5.js. Pin data stored as an array of 40 objects {number, name, function, category}. Hit-testing via dist() between mouse and each pin's center compared to its radius. Keep the HAT sequence state in a single integer variable so draw() can render the correct highlight and label each frame without recomputing pin categories.

Storage: MicroSD, USB, and NVMe over PCIe

Every Raspberry Pi needs somewhere to keep its operating system and files. The option you already know from the Pi 500+ is microSD storage: a small removable memory card, the same physical format used in cameras and some phones, that the Pi reads from and writes to using a built-in card slot. MicroSD storage is inexpensive and easy to swap between boards, which is exactly why it's the default choice for a classroom set of Pi 500+ units — but it's also the slowest storage option available to a Pi 5, and heavy or repeated writes gradually wear the card out.

The Pi 5 adds a second, much faster path to storage through the PCIe interface — Peripheral Component Interconnect Express, a high-speed connection standard originally built for desktop and server computers to talk to graphics cards, network cards, and fast storage. The Pi 5 exposes a single PCIe connector on its underside, reachable with an adapter board, that a maker can use to attach NVMe storage: a solid-state drive that plugs directly into a PCIe connection instead of going through the slower interfaces used by traditional hard drives or SD cards. NVMe storage is dramatically faster than microSD for both reading and writing data, which matters most when a project is reading large model files repeatedly or writing high-resolution video to disk in real time — exactly the kind of workload the AI vision chapters later in this book will ask the Pi 5 to do.

A third, more familiar option sits between those two extremes: a USB 3.0 port, a physical connector supporting data transfer speeds far higher than the older USB 2.0 standard, which the Pi 5 provides in addition to microSD and PCIe. Plugging a fast external USB drive into a USB 3.0 port is a reasonable middle ground — faster than microSD, no adapter board required, though generally still slower than a direct PCIe NVMe connection.

Berry's Key Insight

Notice the pattern: PCIe is the general-purpose highway standard, and NVMe storage is one specific kind of traffic that travels on it. The same PCIe connector could, in principle, carry other fast peripherals in the future — NVMe just happens to be the one nearly every Pi 5 maker plugs in first.

Now that all three options are defined, here's how they compare for a typical Pi 5 project.

Storage Option	Relative Speed	Setup Complexity	Best Fit
MicroSD Storage	Slowest	Simplest — just insert the card	Light projects, easy swapping between boards
USB 3.0 external drive	Fast	Simple — plug into a USB 3.0 port	Extra storage without an adapter board
NVMe Storage (via PCIe)	Fastest	Requires a PCIe adapter board (or a Pi 5 model with a built-in slot)	Real-time video, large model files, frequent writes

Berry's Tip

You don't have to choose just one. A common setup boots from a microSD card for simplicity and mounts an NVMe drive as extra fast storage for the specific folder where video or model files live. Match the storage to the job instead of assuming you need to pick a single "best" option.

Diagram: Storage Speed Comparison

Run the Storage Speed Comparison MicroSim fullscreen

Storage Speed Comparison (interactive chart)

Type: chart sim-id: storage-speed-comparison
Library: Chart.js
Status: Specified

Learning objective: Students will compare (Bloom L4: Analyze) the read and write speeds of microSD, USB 3.0, and NVMe storage on a Raspberry Pi 5 across different workload types.

Chart type: grouped bar chart, responsive Chart.js canvas that resizes to its container width.

Purpose: show how the speed gap between microSD, USB 3.0, and NVMe storage changes depending on the kind of workload — sequential reads (like loading one large video file), random reads (like loading thousands of small model files), and boot time.

X-axis: three workload categories — "Sequential Read," "Random Read (small files)," "Boot Time (seconds, lower is better)."

Y-axis: relative performance score (0-100), except the "Boot Time" category which uses seconds directly with its own scale noted in the tooltip.

Data series: three bars per category, one each for MicroSD Storage (gray), USB 3.0 (indigo #3F51B5), and NVMe Storage (circuit green #2E7D32), using representative values that show NVMe leading substantially on random reads (where the gap is largest) and a smaller relative gap on sequential reads.

Interaction (required): a <select> control above the chart lets students switch the workload emphasis between "Everyday Use" and "AI Vision Project" presets, which re-renders the bar heights to reflect that random-access-heavy AI workloads benefit most from NVMe. Hovering any bar shows an exact tooltip value and a one-sentence explanation of what that workload represents, pulled from the chapter's storage table.

Implementation: Chart.js bar chart with responsive: true and maintainAspectRatio: false inside a fixed-height wrapper div. Store the two presets as separate data arrays and swap the chart's dataset on the <select>'s change event, then call chart.update().

Ports and Connectivity: Moving Data On and Off the Board

Storage handles data sitting still on the board. Several other Pi 5 interfaces handle data moving in and out. You already met the USB 3.0 port above as a storage option, but it serves double duty as a general-purpose connector for keyboards, mice, webcams, and other accessories, just at a much higher transfer speed than USB 2.0.

For getting onto a network reliably, the Pi 5 includes Gigabit Ethernet: a wired network port capable of transferring data at up to roughly one gigabit per second, far faster and more consistent than typical classroom Wi-Fi, and free of the dropped connections that can plague a busy wireless network during a lab session. For projects that stream video to a remote laptop for monitoring, or that pull large model files across the network, a wired Gigabit Ethernet connection removes an entire category of "why is this so slow" troubleshooting.

For sending video out to a screen, the Pi 5 supports dual 4K display output: two independent micro-HDMI connectors, each capable of driving a separate 4K-resolution monitor at the same time. That's a genuine step up from the Pi 500+'s display capability, and it matters for projects where you want one screen showing a live camera feed and a second screen showing debug output or a control dashboard side by side.

Three connectors, three jobs:

• USB 3.0 port — fast general-purpose accessories (drives, webcams, keyboards, mice)
• Gigabit Ethernet — a reliable, fast wired network connection
• Dual 4K display output — two independent monitors, driven at the same time

Before the diagram, it's worth naming what these three interfaces have in common: each one is a physical connector on the board's edge, and knowing where each lives — and what each is for — is the first step to wiring a project correctly instead of guessing.

Diagram: Raspberry Pi 5 Port and Interface Explorer

Run the Raspberry Pi 5 Port and Interface Explorer MicroSim fullscreen

Raspberry Pi 5 Port and Interface Explorer (interactive infographic)

Type: interactive-infographic sim-id: pi5-port-explorer
Library: p5.js
Status: Specified

Learning objective: Students will identify (Bloom L1: Remember) the function of each major port and interface on a Raspberry Pi 5 board.

Canvas: 700x460px, responsive — the board illustration scales as a fraction of width inside windowResized(), with a minimum readable size below which port labels move to a numbered legend instead of inline text.

Layout: a simplified top-down illustration of the Pi 5 board drawn with basic p5.js shapes (rectangles and rounded rectangles, no image file), with labeled regions around its edges: USB-C power connector, two USB 3.0 ports, Gigabit Ethernet port, two micro-HDMI ports (dual 4K display output), the Camera Serial Interface connector, and the PCIe connector on the underside (shown as a dashed-outline callout since it's not visible from the top). The 40-pin GPIO header runs along one long edge.

Interaction: hovering (desktop) or tapping (touch) any labeled region highlights it in gold #D4AF37 and shows a one-sentence tooltip naming the interface and its function. Clicking a region "pins" its infobox open in a panel below the board so multiple regions can be compared side by side; clicking a pinned region again removes it from the panel. A createButton() labeled "Clear All" empties the panel.

Implementation: p5.js. Board regions stored as an array of objects {name, description, boundingBox} with rectangular hit-testing. Track pinned regions in an array and redraw the comparison panel from that array each frame so the layout stays correct after a resize.

Seeing the World: Camera Modules and the Camera Serial Interface

Every hardware feature covered so far helps the Pi 5 move and store data faster. This next one gives it a new sense entirely. The Camera Serial Interface — often shortened to CSI — is a dedicated high-speed connector on the Pi 5 board built specifically for attaching a camera, separate from USB and separate from the GPIO header. Because it's a dedicated connector, a CSI-attached camera can send a continuous stream of image data to the Pi's processor far more efficiently than a typical USB webcam can.

A camera module is the physical accessory that plugs into that CSI connector — a small circuit board carrying a lens and the electronics needed to capture images. At the heart of every camera module is an image sensor: a grid of light-sensitive elements that converts incoming light into an electrical signal, and ultimately into the numeric pixel values a program can process. Three properties of that sensor and its output show up constantly once you start working with cameras. Camera resolution is the number of pixels the sensor captures in each image, usually described as width times height (for example, 1920 by 1080). Frame capture is the act of reading one complete image from the sensor at a single moment in time. A video stream is a continuous, ongoing sequence of captured frames, delivered one after another fast enough that a viewer perceives smooth motion rather than a slideshow of still images.

Some camera modules add a mechanism most webcams also have: an autofocus camera automatically adjusts its lens position so that the subject stays sharp as the distance between the camera and the subject changes, without a person manually turning a focus ring. That matters for a robot or a handheld project where the distance to whatever's being observed keeps changing.

Berry's Gentle Warning: Camera Privacy

A camera module is a real privacy responsibility, not just another sensor. Before you point one anywhere in a classroom, hallway, or home, think about who might be recorded without knowing it, where the footage or images are stored, and whether anyone needs to be told the camera is running. This applies just as seriously to any project later in this book that adds a microphone. Keep the camera pointed at your own workspace during development, and check with your teacher or program lead about your school's or organization's policy before running anything that captures people.

The last camera property worth understanding is how the sensor actually reads out an image, because it changes what a captured frame looks like when something in the scene is moving quickly. A rolling shutter camera reads its image sensor row by row, from top to bottom, over a short but nonzero span of time — which means a fast-moving object can shift position slightly between the top row being captured and the bottom row being captured, producing a skewed or "leaning" look in the final image. A global shutter camera instead captures every pixel in the entire frame at exactly the same instant, eliminating that skew, at the cost of typically being more expensive and sometimes lower resolution than a comparable rolling shutter sensor.

Now that both shutter types are defined, here's how they compare directly.

Property	Rolling Shutter Camera	Global Shutter Camera
How it captures a frame	Reads sensor rows sequentially, top to bottom	Captures the entire frame at one instant
Fast motion result	Can show skew or "jello" distortion	Sharp, undistorted even during fast motion
Typical cost	Lower	Higher
Good fit for	Mostly still or slow-moving subjects	Robotics, sports, anything with fast motion

Diagram: Global vs Rolling Shutter Simulator

Run the Global vs Rolling Shutter Simulator MicroSim fullscreen

Global vs Rolling Shutter Simulator (MicroSim)

Type: microsim sim-id: global-vs-rolling-shutter-simulator
Library: p5.js
Status: Specified

Learning objective: Students will analyze (Bloom L4: Analyze) how a rolling shutter camera's row-by-row capture produces a skewed image of a fast-moving object compared to a global shutter camera's single-instant capture.

Canvas: 700x460px, responsive — split into two side-by-side "captured frame" panels (stacked below 560px wide) labeled "Rolling Shutter" and "Global Shutter," recomputed as fractions of width/height inside windowResized().

Layout: a simple moving object (a striped vertical bar, drawn with rect()) crosses a scene at a controllable speed. Each panel shows what that panel's camera type "captured" as a still frame: the global shutter panel always shows an undistorted straight bar; the rolling shutter panel shows the bar progressively skewed based on the current speed setting, simulating the row-by-row readout delay.

Controls: a createSlider() labeled "Object Speed" (range 1-10, default 3); a createButton() labeled "Capture Frame" that freezes both panels showing the current simulated result; a createButton() labeled "Resume" that restarts the moving object.

Interaction: as "Object Speed" increases, the rolling shutter panel's captured skew visibly increases while the global shutter panel remains unaffected, letting students directly compare the two side effects of the same motion. After clicking "Capture Frame," hovering either panel shows a one-sentence tooltip naming which shutter type produced that result and why.

Implementation: p5.js. Model the rolling shutter skew by offsetting each horizontal row of the drawn bar by an amount proportional to (row index) times (current speed) times a small readout-delay constant, drawn with many thin horizontal rect() slices rather than one solid shape. The global shutter panel draws the same bar with zero offset regardless of speed. Keep both panels' object position synchronized from a single shared position variable so the comparison stays fair.

Power and Cooling: Keeping the Pi 5 Fed and Cool

A faster board draws more power and generates more heat than the Pico or even the Pi 500+, so power delivery and cooling deserve their own attention rather than an afterthought. Every power source has a power supply rating: the maximum voltage and current, typically written as something like "5V 5A," that a given adapter can safely deliver. The Pi 5 specifically expects power over USB-C power delivery — a USB-C connector combined with a communication protocol that lets the Pi and the power adapter negotiate how much current the adapter can safely supply before power actually starts flowing at that level. An underrated adapter, or a cheap USB-C cable not built for higher current, can cause a Pi 5 to brown out or throttle itself under load even though it appears to be receiving power.

Berry's Tip

Not all USB-C cables are created equal — some are wired for charging phones at low current only. For a Pi 5, use the official Raspberry Pi power supply or a cable and adapter explicitly rated for at least 5V at 5A. A flaky power supply causes some of the strangest, hardest-to-diagnose bugs in this entire book.

Heat is the other side of that same coin. Running a fast processor, especially under the kind of sustained load a real-time vision project creates, raises the chip's temperature. A heat sink is a piece of metal, usually aluminum or copper with fins to increase surface area, attached directly to the processor to draw heat away from the chip and spread it out so it can escape into the surrounding air more easily. A heat sink alone works passively — no moving parts, no power required — but it has limits. Active cooling adds a small fan, usually mounted on or near the heat sink, that moves air across it to carry heat away faster than passive convection alone can manage. For any project that keeps the Pi 5's processor busy for extended stretches — which describes essentially every real-time AI vision project later in this book — active cooling isn't optional polish, it's the difference between sustained full performance and a processor that quietly slows itself down.

That self-slowing behavior has a name: thermal throttling is the automatic process by which a processor reduces its own operating speed once its temperature crosses a safety threshold, trading performance for protection against heat damage. Thermal throttling isn't a malfunction — it's a deliberate safety feature — but it can look exactly like a mysterious performance bug if you don't know to check for it, since a throttled Pi 5 keeps running, just more slowly and with no obvious error message.

You've Got This!

If a project that ran fine for two minutes mysteriously slows to a crawl on minute three, don't assume your code broke — check the temperature first. A Pi running hot and throttling itself is one of the sneakiest "bugs" in this book, and now you know exactly what to look for.

Checking that temperature takes one short command, and it's worth explaining before you see it: the Pi's operating system exposes a small utility called vcgencmd that reports information straight from the board's firmware, including the current chip temperature and whether the board is currently throttled. Running it looks like this in a terminal:

vcgencmd measure_temp
vcgencmd get_throttled

The first line prints the current processor temperature in degrees Celsius. The second prints a status code — throttled=0x0 means everything is running at full speed with no issues, while any other value indicates the board has throttled itself, undervolted, or both at some point since boot.

Now that heat sinks, active cooling, and thermal throttling are all defined, the chart below shows how they interact under a sustained workload.

Diagram: Thermal Throttling and Active Cooling Chart

Run the Thermal Throttling and Active Cooling Chart MicroSim fullscreen

Thermal Throttling and Active Cooling Chart (interactive chart)

Type: chart sim-id: thermal-throttling-chart
Library: Chart.js
Status: Specified

Learning objective: Students will analyze (Bloom L4: Analyze) how active cooling and heat sink choice affect processor temperature and the onset of thermal throttling under sustained load.

Chart type: line chart, responsive Chart.js canvas.

Purpose: show simulated CPU temperature over ten minutes of sustained load under three cooling configurations, and mark the point at which each configuration crosses the thermal throttling threshold.

X-axis: time under load, in minutes (0 to 10).

Y-axis: CPU temperature in degrees Celsius, with a clearly marked horizontal reference line at the throttling threshold (approximately 85°C).

Data series: three lines — "No Cooling" (red, rises quickly and crosses the threshold early), "Heat Sink Only" (gold #D4AF37, rises more slowly and crosses the threshold later), and "Active Cooling" (circuit green #2E7D32, levels off below the threshold and never throttles).

Interaction (required): a set of three checkboxes lets students toggle each line's visibility independently to compare configurations one at a time or together. Hovering any point on a line shows a tooltip with the exact simulated temperature and, if that configuration has crossed the threshold by that time, a note reading "Throttling active — clock speed reduced."

Implementation: Chart.js line chart with responsive: true and maintainAspectRatio: false. Precompute each series as an array of 11 values (one per minute) following a simple approach-to-asymptote curve, with the "No Cooling" and "Heat Sink Only" curves exceeding the threshold value partway through. Wire the three checkboxes' change events to toggle chart.data.datasets[i].hidden and call chart.update().

Bringing It Together

You now know how a Raspberry Pi 5 stores its files, moves data on and off the board, sees the world through a camera, and keeps itself running cool under load — the physical foundation every AI vision project in this book depends on. None of this hardware does anything on its own yet. The next chapter turns to the software side: setting up a Python environment, installing libraries, and managing your project with Git so that the code you write on this hardware is organized, reproducible, and easy to share. After that, the AI HAT+ chapter puts a name to the neural processing unit sitting on this board's GPIO header, and the real-time object detection chapter after that finally asks this camera, this storage, and this cooling system to work together on a live video feed.

You Unlocked a Superpower!

That's berry solid hardware knowledge! You can now look at a Pi 5 project brief and know exactly which storage, camera, and cooling choices actually fit the job instead of guessing. STEM is our superpower, and this one's now yours. Let's build something — see you in Chapter 15!

See Annotated References