The Robot Whisperer

Wait — how is this different from what I already do?

You're a web developer. When you write JavaScript or Go for the web, you usually save a file and it just runs — sometimes it even reloads by itself in the browser. C++ is a little more old-fashioned, and that's on purpose.

So the C++ loop is always three steps:

1. Write your code in a file (ending in .cpp).
2. Compile it — turn it into a runnable program.
3. Run the program.

What is a "compiler" exactly?

A compiler is just another program. The most common free ones are called g++ (part of a toolkit called GCC) and clang. You'll type a command, point it at your file, and it hands you back a program you can run.

Installing your tools

You have two "worlds" to set up. Don't worry — you only need the first one for now.

World 1 — C++ on your computer (for learning the language)

Pick the guide for your operating system below and follow it top to bottom. Every step is spelled out — you don't need to already know any of these tools.

gcc.exe (Rev...) 14.2.0
g++.exe (Rev...) 14.2.0
GNU gdb (GDB) 15.x

And for everyone — a code editor

1. Install VS Code (free) — you may already use it for React.
2. Open VS Code, click the Extensions icon on the left sidebar (the four little squares).
3. Search for C/C++ and install the one by Microsoft. This gives you error highlighting, autocomplete, and one-click running.
4. Now point that extension at the compiler you just installed. Open the Command Palette (Ctrl+Shift+P, or Cmd+Shift+P on Mac), type Preferences: Open User Settings (JSON), and press Enter. Your global settings.json opens.
5. Add these four entries at the end of the JSON object, then save with Ctrl+S:

   {
     "C_Cpp.default.compilerPath": "C:/msys64/ucrt64/bin/g++.exe",
     "C_Cpp.default.cStandard": "c17",
     "C_Cpp.default.cppStandard": "gnu++17",
     "C_Cpp.default.intelliSenseMode": "windows-gcc-x64"
   }

   If your settings.json already has entries, paste just the four lines inside the existing outer { } — and make sure the line before them ends with a comma.

World 2 — The hardware toolkit (for later, Module 5+)

When we start moving real things, you'll install PlatformIO (an extension inside VS Code) and buy an ESP32 board. We'll cover that when we get there. Ignore it for now.

Your first program

Make a file called hello.cpp and type this in exactly:

// This line borrows a "toolbox" for printing to the screen.
#include <iostream>

// Every C++ program starts running inside "main".
int main() {
    std::cout << "Hello! I am about to control robots.\n";
    return 0;
}

Now let's read every piece, because these appear in every program you'll ever write:

• #include <iostream> — "Please bring me the input/output toolbox." iostream = "in-out-stream." It's what lets us print things.
• int main() { ... } — the starting door of your program. When you run the program, the computer walks through this door and does whatever is inside the { }.
• std::cout — "console out." Think of it as the screen. The << arrows push text toward the screen.
• "...\n" — the text to show. \n means "new line" (like pressing Enter).
• return 0; — tells the computer "I finished successfully." 0 means "all good, no errors."
• Every statement ends with a semicolon ; — like a full stop at the end of a sentence. Forgetting it is the #1 beginner error.

Compile and run it

# Step 1: compile hello.cpp into a program called "hello"
g++ hello.cpp -o hello

# Step 2: run it (Mac/Linux)
./hello

# On Windows the program is hello.exe, so just type:
hello.exe

Hello! I am about to control robots.

Variables: labelled boxes

#include <iostream>
int main() {
    int age = 10;              // a whole number
    double price = 4.50;       // a number with a decimal point
    bool isFun = true;         // true or false only
    char grade = 'A';          // a single character

    std::cout << "Age: " << age << "\n";
    std::cout << "Price: " << price << "\n";
    return 0;
}

Age: 10
Price: 4.5

The types you'll actually use

• int — a whole number like 7 or -40.
• double — a decimal number like 3.14.
• bool — only true or false (like a light switch).
• char — one single letter or symbol, written in single quotes: 'x'.
• std::string — a piece of text like "door" (needs #include <string>).

Doing math

int a = 7, b = 2;
std::cout << a + b << "\n";   // 9
std::cout << a - b << "\n";   // 5
std::cout << a * b << "\n";   // 14
std::cout << a / b << "\n";   // 3  <-- surprise! (see warning)
std::cout << a % b << "\n";   // 1  (remainder: "modulo")

Making decisions: if

int pin = 1234;

if (pin == 1234) {
    std::cout << "Correct! Door opens.\n";
} else {
    std::cout << "Wrong PIN. Stay locked.\n";
}

Other comparisons: > greater, < less, >=, <=, and != ("not equal"). You can combine checks with && ("and") and || ("or").

Repeating: loops

// A "for" loop: repeat a known number of times.
for (int i = 1; i <= 3; i++) {
    std::cout << "Blink number " << i << "\n";
}

// A "while" loop: repeat as long as something is true.
int fuel = 3;
while (fuel > 0) {
    std::cout << "Fuel left: " << fuel << "\n";
    fuel--;   // take one away each round
}

Blink number 1
Blink number 2
Blink number 3
Fuel left: 3
Fuel left: 2
Fuel left: 1

Reading the for loop out loud: "Start i at 1; keep going while i is 3 or less; after each round, add 1 to i (i++)."

Functions: naming a bundle of steps

#include <iostream>

// A recipe named "add" that takes two ints and hands back an int.
int add(int x, int y) {
    return x + y;
}

// A recipe that returns nothing (void) — it just does something.
void greet(std::string name) {
    std::cout << "Hello, " << name << "!\n";
}

int main() {
    int total = add(3, 4);   // total is now 7
    std::cout << total << "\n";
    greet("future engineer");
    return 0;
}

7
Hello, future engineer!

Anatomy of a function: int add(int x, int y) means "a recipe called add that gives back an int, and needs two ints to work." The stuff in the brackets are parameters (ingredients). void means "gives nothing back."

A note about header files (you'll see these everywhere)

Big programs get split into two kinds of files: .h (header — the "menu" that announces what functions exist) and .cpp (the "kitchen" where they're actually written). For now you can keep everything in one .cpp file. Just know that when you see #include "lock.h", it means "bring in the menu from lock.h."

Where do variables live?

Stack vs heap — two kinds of storage

• The stack is like a stack of sticky notes on your desk. Fast, automatic, and cleaned up for you the moment a function ends. Almost everything you've written so far lives here.
• The heap is like a big warehouse where you can ask for storage that stays around as long as you want — but you are responsible for giving it back when you're done. Forget, and you've got a mess (a "leak").

Pointers: a note that says "it's over there"

#include <iostream>
int main() {
    int score = 42;

    // &score means "the address (locker number) of score".
    int* p = &score;   // p is a pointer that points AT score

    std::cout << score  << "\n";  // 42  (the value)
    std::cout << p      << "\n";  // something like 0x7ffe...  (the address)
    std::cout << *p     << "\n";  // 42  (*p means "go to that locker and read it")

    *p = 100;   // change the value THROUGH the pointer
    std::cout << score << "\n";   // 100 — we changed score without touching it directly!
    return 0;
}

42
0x7ffee3b4c9ac
42
100

Two little symbols do all the work:

• &thing = "the address of thing" (where's its locker?).
• *pointer = "the value at that address" (open the locker and look inside). This is called dereferencing.

Asking for warehouse space: new and delete

int* box = new int;   // ask the warehouse for a locker
*box = 7;             // put 7 in it
std::cout << *box;    // 7
delete box;           // GIVE THE LOCKER BACK when done
box = nullptr;        // good habit: mark it as "points to nothing now"

The grown-up solution: RAII & smart pointers

#include <memory>
#include <iostream>

int main() {
    // unique_ptr owns the locker and deletes it AUTOMATICALLY.
    std::unique_ptr<int> box = std::make_unique<int>(7);
    std::cout << *box << "\n";   // 7
    // No delete needed! When 'box' goes out of scope, cleanup happens for you.
    return 0;
}

Text: std::string vs old C-strings

You'll see two ways to hold text. Prefer the first:

#include <string>
std::string name = "front door";   // the friendly, safe way
std::cout << name.length();        // 10 — it knows its own size

// The old "C-string" is just an array of chars ending in a hidden 0.
// You'll meet these on hardware. They're easy to overflow, so be careful.
const char* old = "hi";

What's an "object"?

Blueprint = class. Real item made from it = object (also called an instance). One blueprint, many objects — like one cookie cutter, many cookies.

#include <iostream>
#include <string>

class Lock {
public:                           // stuff the outside world may use
    std::string name;             // a FACT the lock stores (a "member")
    bool isOpen = false;          // starts locked

    // ACTIONS the lock can do ("methods"):
    void open() {
        isOpen = true;
        std::cout << name << " is now OPEN.\n";
    }
    void lock() {
        isOpen = false;
        std::cout << name << " is now LOCKED.\n";
    }
};

int main() {
    Lock front;               // build one real lock from the blueprint
    front.name = "Front door";
    front.open();             // call its action with a dot
    front.lock();
    return 0;
}

Front door is now OPEN.
Front door is now LOCKED.

Notice the dot: front.open() means "tell the front object to run its open action." The data inside a class is called members; the actions are methods.

Constructors: how a thing is born

class Lock {
public:
    std::string name;

    // Constructor: runs automatically when a Lock is made.
    Lock(std::string n) {
        name = n;
        std::cout << "A lock named " << name << " was installed.\n";
    }
};

int main() {
    Lock back("Back door");   // constructor runs right here
    return 0;
}

A lock named Back door was installed.

There's also a destructor (~Lock()) that runs when the object goes away — the perfect place to "turn off the motor" or "release the pin." That's RAII from Module 2 in action.

Public vs private: hiding the wiring

class Lock {
private:                     // only the class itself can touch these
    int secretPin = 1234;

public:                      // the buttons outsiders press
    bool tryPin(int guess) {
        return guess == secretPin;   // checks safely, never reveals the pin
    }
};

This is called encapsulation — a fancy word for "keep the risky stuff inside and only expose safe buttons." Hugely important for a lock: nobody outside should be able to just read the PIN.

Inheritance: family trees of things

#include <iostream>

class Lock {                        // the parent (base class)
public:
    // "virtual" means: children are allowed to replace this.
    virtual void open() {
        std::cout << "A generic lock opens.\n";
    }
};

class ServoLock : public Lock {     // a child of Lock
public:
    void open() override {          // replace the parent's version
        std::cout << "The servo turns the bolt.\n";
    }
};

class SolenoidLock : public Lock {
public:
    void open() override {
        std::cout << "The solenoid clicks open.\n";
    }
};

int main() {
    ServoLock a;
    SolenoidLock b;
    a.open();   // The servo turns the bolt.
    b.open();   // The solenoid clicks open.
    return 0;
}

The servo turns the bolt.
The solenoid clicks open.

The magic word virtual plus override is called polymorphism — "many shapes." It means you can keep a list of different lock types and just call open() on each; every one does its own correct thing. This is exactly how real device drivers are organized.

auto: let the compiler figure out the type

auto age = 10;        // compiler knows: this is an int
auto price = 4.5;     // this is a double
auto name = std::string("door");   // a string

Vectors: a list that grows

#include <iostream>
#include <vector>
#include <string>

int main() {
    std::vector<std::string> doors;   // an empty list of door names

    doors.push_back("Front");         // add to the end
    doors.push_back("Back");
    doors.push_back("Garage");

    std::cout << "We have " << doors.size() << " doors.\n";

    // "range-based for": visit each item, no counter needed.
    for (const auto& d : doors) {
        std::cout << "- " << d << "\n";
    }
    return 0;
}

We have 3 doors.
- Front
- Back
- Garage

That for (const auto& d : doors) line reads as: "for each door d in doors, ...". The & means "don't make a wasteful copy, just look at the real one," and const means "I promise not to change it." A very common, very good habit.

Maps: look things up by a key

#include <iostream>
#include <map>
#include <string>

int main() {
    std::map<std::string, bool> locked;
    locked["Front"]  = true;
    locked["Garage"] = false;

    if (locked["Front"]) {
        std::cout << "Front door is locked.\n";
    }
    return 0;
}

Front door is locked.

Lambdas: a mini-function with no name

#include <iostream>

int main() {
    // A lambda stored in a variable. [] starts it.
    auto doubleIt = [](int x) { return x * 2; };

    std::cout << doubleIt(5) << "\n";   // 10
    return 0;
}

Handling "maybe" with std::optional

Sometimes an answer might not exist — "find the lock named X" could find nothing. Instead of returning a fake value, C++ has std::optional, which means "maybe a value, maybe nothing." It saves you from a lot of bugs.

#include <iostream>
#include <optional>

std::optional<int> findPin(bool known) {
    if (known) return 1234;
    return std::nullopt;   // "nothing to give"
}

int main() {
    auto result = findPin(true);
    if (result.has_value()) {
        std::cout << "PIN is " << result.value() << "\n";
    } else {
        std::cout << "No PIN found.\n";
    }
    return 0;
}

PIN is 1234

A word on errors: exceptions vs. error codes

When something goes wrong, C++ can "throw an exception" (like raising an alarm that jumps out of the function). On big computers that's fine. But on tiny hardware chips, exceptions are often turned off because they cost memory — there, people return error codes or use optional instead. Just know both styles exist; we'll use the hardware-friendly one later.

You've already met these without being told. In Module 1 we mentioned uint8_t holds "0 to 255" — why that odd number? In Module 2 the computer printed a pointer as 0x7ffee3b4c9ac — what is that? Both answers live here. And from Module 5 onward, when we start flipping individual pins on a chip, this becomes the language you think in.

The one idea behind every number system

The size of that alphabet is called the base (or radix). And each new column to the left is worth base times the column to its right. That single rule — called positional notation — is the whole trick. Everything below is just that rule with different bases.

Decimal (base 10) — the one you already know

Digits: 0 1 2 3 4 5 6 7 8 9 — ten of them.

Why it exists: for the least technical reason imaginable — humans have ten fingers. There is nothing mathematically special about ten. It is a biological accident that became the world's default.

Decimal 3,507  —  every slot is worth 10× the one to its right

   1000s   100s   10s   1s        <- place value (10^3 10^2 10^1 10^0)
      3      5      0    7        <- our digits

   3×1000 + 5×100 + 0×10 + 7×1
   = 3000 +   500 +    0 +  7
   = 3507

You do this every day without noticing. You already know that in 3507 the 3 "means" three thousand. Hold on to that instinct — binary and hex work identically, only the column values change.

Binary (base 2) — the one the machine actually uses

Digits: 0 and 1 — that's it. One binary digit is called a bit.

Why we need it: it's not a stylistic choice, it's physics. A wire is high or low. An LED is lit or dark. A GPIO pin (Module 5) is HIGH or LOW. Binary is simply the number system that matches the hardware.

Each column doubles as you move left: 1, 2, 4, 8, 16, 32, 64, 128...

Binary 1011 0110  —  every slot is worth 2× the one to its right

   128  64  32  16   8   4   2   1     <- place value (2^7 ... 2^0)
     1   0   1   1   0   1   1   0     <- our bits

   128 +  0 + 32 + 16 +  0 +  4 +  2 +  0
   = 182

Bits, nibbles and bytes

One BYTE = 8 bits = 2 hex digits = a number from 0 to 255

   bits    1111 1111
   nibble  ────  ────      each 4-bit half is a "nibble"
   hex        F     F
   value                255   (the biggest an 8-bit box can hold)

   That is exactly why uint8_t stops at 255, and why colours,
   pixels and bytes of memory keep bumping into the number 255.

This is the answer to the Module 1 mystery. uint8_t means "unsigned integer, 8 bits." Eight switches give 2⁸ = 256 possible combinations. Counting from zero, the largest is 255. Nothing arbitrary about it.

Where you actually meet binary

• Pin states — digitalWrite(pin, HIGH) is writing a single bit to the physical world.
• Flags & bitmasks — packing eight yes/no settings into one byte instead of eight separate variables. Priceless when a chip has 2 KB of RAM.
• Permissions — read/write/execute is three bits.
• Network masks — 255.255.255.0 is prettier as 11111111.11111111.11111111.00000000, which is why it's also written /24 (24 ones).
• Why 1 KB = 1024 bytes — because 2¹⁰ = 1024, and computers count in powers of two, not powers of ten.

Hexadecimal (base 16) — binary for humans

Digits: 0 1 2 3 4 5 6 7 8 9 A B C D E F — sixteen. Once we exhaust 9, we borrow letters: A is ten, B eleven, and so on up to F = fifteen.

Why we need it: hex is not a third way computers think. Computers only know binary. Hex exists purely so that we can write and read binary without losing our minds. One byte — eight bits — is always exactly two hex digits. Tidy.

Hexadecimal 0x2F  —  every slot is worth 16× the one to its right

   16s   1s          <- place value (16^1 16^0)
     2    F          <- our digits   (F means 15)

   2×16 + 15×1
   =  32 + 15
   = 47

The table worth memorising

Learn these sixteen rows and you can convert between binary and hex instantly, for the rest of your career. It's the only rote learning in this whole course.

Where you actually meet hex

• Memory addresses — 0x7ffee3b4c9ac, the pointer we printed back in Module 2. Now you can read it.
• Colours — #FF8800 is three bytes: red 255, green 136, blue 0. The accent colour on this very site is #22D3EE.
• Hardware registers — an ESP32 datasheet will tell you a control register lives at 0x3FF44004. Nobody writes that in binary.
• MAC addresses — A4:CF:12:9B:00:1E, six bytes.
• Bit masks in firmware — 0xFF means "all eight bits set," and you learn to see that instantly.
• Hashes, UUIDs, checksums — long strings of bytes, always shown as hex.

Converting between them, by hand

There are six directions, but really only three ideas. Learn these and you never need a calculator.

1. Binary → Decimal (add the place values)

Write the place values above the bits, add the columns that hold a 1. Shown above with 1011 0110 = 182.

2. Decimal → Binary (divide by 2, read remainders upward)

Convert 182 to binary  —  divide by 2, keep the remainders

   182 ÷ 2 = 91  remainder 0    <- least significant bit (rightmost)
    91 ÷ 2 = 45  remainder 1
    45 ÷ 2 = 22  remainder 1
    22 ÷ 2 = 11  remainder 0
    11 ÷ 2 =  5  remainder 1
     5 ÷ 2 =  2  remainder 1
     2 ÷ 2 =  1  remainder 0
     1 ÷ 2 =  0  remainder 1    <- most significant bit (leftmost)

   Now read the remainders BOTTOM to TOP:  1011 0110

   Check: 128 + 32 + 16 + 4 + 2 = 182  ✓

3. Hex → Decimal (multiply by powers of 16)

Shown above with 0x2F = 2×16 + 15 = 47. For a longer number like 0x1A3: 1×256 + 10×16 + 3×1 = 256 + 160 + 3 = 419.

4. Decimal → Hex (divide by 16, read remainders upward)

Convert 47 to hexadecimal  —  divide by 16, keep the remainders

    47 ÷ 16 = 2  remainder 15   -> 15 is "F"
     2 ÷ 16 = 0  remainder  2   -> 2 is "2"

   Read BOTTOM to TOP:  2F        so 47 = 0x2F

   Check: 2×16 + 15 = 47  ✓

5. Binary → Hex (group into fours — the one you'll use most)

Binary -> Hex  —  slice into groups of 4 bits, from the RIGHT

   1011 0110
   ────  ────
     |     |
     B     6          (1011 = 11 = B,   0110 = 6)

   So 1011 0110  =  0xB6

   Check: 11×16 + 6 = 176 + 6 = 182  ✓  (same number as before)

6. Hex → Binary (expand each digit into four bits)

Hex -> Binary  —  expand each digit into its own 4 bits

   0x3A
     |  |
     3  A
     |  |
   0011 1010          (3 = 0011,   A = 10 = 1010)

   So 0x3A  =  0011 1010  =  32 + 16 + 8 + 2 = 58

Notice that 5 and 6 need no arithmetic whatsoever — just the sixteen-row table. That is the entire reason hexadecimal was invented, and why it beat octal for modern work: bytes are 8 bits, and 8 divides evenly into two hex digits but not into octal's 3-bit groups.

Writing them in C++

The compiler doesn't care which base you type — it converts everything to binary anyway. Prefixes just tell it how to read what you wrote. Use whichever base makes your intent clearest.

#include <iostream>

int main() {
    // Three ways to write the SAME number. All of these are 255.
    int dec = 255;         // decimal      — no prefix
    int bin = 0b11111111;  // binary       — 0b prefix (C++14 and newer)
    int hex = 0xFF;        // hexadecimal  — 0x prefix

    std::cout << (dec == bin) << " " << (bin == hex) << "\n";  // 1 1 (both true)

    // Digit separators make long literals readable (C++14).
    int mask = 0b1011'0110;   // same as 0xB6, same as 182
    std::cout << mask << "\n";
    return 0;
}

1 1
182

Printing a number in another base

#include <iostream>
#include <bitset>

int main() {
    int n = 182;

    std::cout << std::dec << n << "\n";           // 182
    std::cout << std::hex << n << "\n";           // b6
    std::cout << std::bitset<8>(n) << "\n";       // 10110110

    // showbase puts the 0x prefix back on
    std::cout << std::showbase << std::hex << n << "\n";   // 0xb6

    std::cout << std::dec;   // IMPORTANT: put the stream back to decimal!
    return 0;
}

182
b6
10110110
0xb6

The leading-zero trap

#include <iostream>

int main() {
    int a = 13;    // thirteen, as you'd expect
    int b = 013;   // NOT thirteen! A leading zero means OCTAL -> 11
    int c = 0x13;  // hexadecimal -> 19

    std::cout << a << " " << b << " " << c << "\n";   // 13 11 19
    return 0;
}

13 11 19

Why this matters: bit manipulation

The four operators, in plain words:

• x | mask (OR) — turn bits on. Anywhere the mask has a 1, the result has a 1.
• x & mask (AND) — test or keep bits. Only bits set in both survive.
• x ^ mask (XOR) — flip bits. Wherever the mask has a 1, the bit toggles.
• ~x (NOT) — invert everything. Combined with AND it becomes "turn this bit off."
• 1 << n (shift) — build a mask. Slide a single 1 left n places. 1 << 3 is 0000 1000 = 8.

#include <cstdint>
#include <iostream>
#include <bitset>

int main() {
    uint8_t flags = 0b0000'0000;   // 8 little switches, all OFF

    flags |= (1 << 2);    // SET   bit 2 (turn it on)  -> 0000 0100
    flags |= (1 << 5);    // SET   bit 5               -> 0010 0100

    bool bit2On = flags & (1 << 2);   // TEST bit 2    -> true

    flags &= ~(1 << 2);   // CLEAR bit 2 (turn it off) -> 0010 0000
    flags ^= (1 << 5);    // FLIP  bit 5               -> 0000 0000

    std::cout << std::bitset<8>(flags) << " " << bit2On << "\n";
    return 0;
}

00000000 1

Unpacking a colour — hex, shifts and masks together

#include <cstdint>
#include <iostream>

int main() {
    // A colour is just three bytes packed into one number:
    //   0xFF 88 00  ->  R=0xFF (255), G=0x88 (136), B=0x00 (0)
    uint32_t orange = 0xFF8800;

    uint8_t r = (orange >> 16) & 0xFF;   // slide right 16 bits, keep last 8
    uint8_t g = (orange >>  8) & 0xFF;
    uint8_t b = (orange      ) & 0xFF;

    std::cout << (int)r << "," << (int)g << "," << (int)b << "\n";
    return 0;
}

255,136,0

Read (orange >> 16) & 0xFF as: "slide the number right by 16 bits so the red byte lands at the bottom, then use 0xFF to keep only those bottom 8 bits." This exact pattern shows up in every graphics library, every LED strip driver, and every network packet parser you will ever read.

The 255 wall

#include <cstdint>
#include <iostream>

int main() {
    uint8_t x = 255;   // 1111 1111 — the biggest an 8-bit box holds
    x = x + 1;         // no room for a 9th bit, so it wraps to 0000 0000

    std::cout << (int)x << "\n";   // 0   (NOT 256!)
    return 0;
}

0

The payoff: ASCII — where all four systems meet letters

How to read the chart

Every row is one character, shown in all four number systems at once. Find A in the ASCII column and read across its row: decimal 65, binary 01000001, octal 101, hex 41. Those aren't four different facts — they're one number written four ways, exactly like the conversions you just learned. Three landmarks worth memorising:

• '0'–'9' live at 48–57 (hex 0x30–0x39) — note the hex digit matches: '7' is 0x37.
• 'A'–'Z' start at 65 (0x41).
• 'a'–'z' start at 97 (0x61) — exactly 32 more than the capitals. And 32 is 0010 0000: a single bit. Lower-case and upper-case letters differ by one bit (bit 5). Case conversion is bit manipulation — the section you just read.

Rows 0–31 look strange (NUL, BEL, ESC...) — those are control characters: instructions, not letters, from the teleprinter era. Most are museum pieces, but four you will meet constantly: LF (10) is \n, the newline you've typed in every program so far; CR (13) is \r (Windows line endings are CR LF — 13 10); HT (9) is Tab; NUL (0) is the hidden terminator at the end of every C-string from Module 2. And SP (32) is just the space bar.

The classic Decimal–Binary–Octal–Hex–ASCII conversion chart, all 128 codes. (Generated from the same toString(base) conversions this section teaches — the chart and the lesson can't disagree.)

Using it from C++

In C++ a char is a small number — the chart is built into the type system. Print it as a character or as its code; it's the same byte:

#include <iostream>

int main() {
    char letter = 'A';
    std::cout << (int)letter << "\n";          // 65 — the chart's Decimal column

    // Lowercase = uppercase + 32. And 32 is exactly bit 5!
    std::cout << (char)(letter + 32) << "\n";  // 'a'  (65 + 32 = 97)
    std::cout << (char)('a' & ~(1 << 5)) << "\n";  // 'A' — clear bit 5 to upper-case

    // Digit characters are NOT their values: '7' is code 55.
    char digit = '7';
    int value = digit - '0';                   // 55 - 48 = 7. The classic trick.
    std::cout << value << "\n";

    // Text is just bytes:
    for (char c : {'J', 'B'}) std::cout << (int)c << " ";   // 74 66
    std::cout << "\n";
    return 0;
}

65
a
A
7
74 66

Practice — do these on paper

No calculator. Paper is the point: the muscle memory is what makes hex readable at a glance later.

1. Convert 0110 1101 to decimal.
2. Convert 200 to binary, then to hex.
3. Convert 0xC4 to binary, then to decimal.
4. What single hex byte turns on bits 0, 1, 2 and 3 and nothing else?
5. The colour #22D3EE — what are its red, green and blue values in decimal?
6. Why can a uint8_t never hold the number 300?

Electricity in one picture

• Voltage (V) — the push. Our chips use small, safe pushes like 3.3V or 5V. (Wall sockets are ~230V — we never touch those directly.)
• Current (A, or milliamps mA) — the flow. Too much through a small part burns it out.
• Resistance (Ω, "ohms") — slows the flow. A resistor is a part whose only job is to slow current down so delicate parts survive.

They're linked by one tiny formula, Ohm's Law: Voltage = Current × Resistance. You rarely do the math by hand as a beginner, but it's why we add a resistor in front of an LED: to keep the current gentle.

What is a microcontroller?

Pins: the chip's fingers

Those little metal pins are called GPIO — "General Purpose Input/Output." Each pin can either:

• Output — the chip pushes electricity out to turn something on (light an LED, spin a motor).
• Input — the chip reads whether electricity is coming in (is the button pressed?).

Digital vs analog

• Digital = only two states: ON (HIGH) or OFF (LOW). Like a light switch. A button is digital.
• Analog = a smooth range in between, like a dimmer knob. A light sensor gives analog readings.

The breadboard: building without soldering

Pull-up and pull-down resistors (the button puzzle)

Here's a subtle thing that confuses everyone at first. When a button is not pressed, the input pin is connected to... nothing. And "nothing" makes the chip read random garbage (called "floating"). To fix it, we gently tie the pin to a known state with a resistor:

• Pull-up: resistor gently holds the pin HIGH; pressing the button pulls it LOW.
• Pull-down: resistor gently holds the pin LOW; pressing pulls it HIGH.

PWM: faking "in-between" with fast blinking

Datasheets & staying safe

Every part comes with a datasheet — a document telling you its voltage, current limits, and what each pin does. You don't read all of it; you skim for "which pin is which" and "max voltage."

Your shopping list for the hands-on parts

• 1× ESP32 dev board (with USB cable)
• 1× breadboard + a pack of jumper wires
• A few LEDs and 220Ω resistors
• 1× push button
• 1× small servo motor (SG90) — this becomes our "lock"
• Later: a relay module or solenoid lock, an RFID reader (RC522)

Your first real circuit, drawn out

This is exactly the circuit Milestone 5 asks you to build. Trace every wire with your finger before you plug anything in — and hover the wires and parts for hints:

The new shape of a hardware program

// This runs ONCE when the board powers up.
void setup() {
    pinMode(2, OUTPUT);   // pin 2 will PUSH power out (to an LED)
}

// This runs FOREVER, top to bottom, again and again.
void loop() {
    digitalWrite(2, HIGH);   // LED ON
    delay(500);              // wait 500 milliseconds (half a second)
    digitalWrite(2, LOW);    // LED OFF
    delay(500);              // wait again
}

The LED blinks: on for 0.5s, off for 0.5s, forever.
(No text on a screen — the "output" is a physical light!)

New words, all plain once named:

• pinMode(2, OUTPUT) — "Pin 2, get ready to push power out."
• digitalWrite(2, HIGH) — "Pin 2, turn ON." LOW = OFF.
• delay(500) — "Pause for 500 milliseconds." (1000 ms = 1 second.)

Reading a button

The wiring is the Milestone 5 circuit from Module 5 — LED (through its 220Ω resistor) on GPIO 2, button on GPIO 4, both returning to GND.

const int BUTTON = 4;   // button wired to pin 4
const int LED    = 2;

void setup() {
    pinMode(LED, OUTPUT);
    pinMode(BUTTON, INPUT_PULLUP);  // use the chip's built-in pull-up
    Serial.begin(115200);           // open a text channel back to the computer
}

void loop() {
    // With INPUT_PULLUP, the pin reads HIGH normally,
    // and LOW when the button is actually pressed.
    if (digitalRead(BUTTON) == LOW) {
        digitalWrite(LED, HIGH);
        Serial.println("Button pressed!");   // print to the computer
    } else {
        digitalWrite(LED, LOW);
    }
}

Hold the button → the LED lights up.
In the Serial Monitor on your computer: "Button pressed!" printed repeatedly.

Serial is your best friend for hardware — it's how the chip "talks back" to your computer so you can see what's happening. It's the hardware version of std::cout. Open the "Serial Monitor" in PlatformIO to read it.

The bounce problem

unsigned long lastPress = 0;

void loop() {
    if (digitalRead(BUTTON) == LOW) {
        // only accept a press if 200ms passed since the last one
        if (millis() - lastPress > 200) {
            Serial.println("Clean press!");
            lastPress = millis();
        }
    }
}

millis() gives the number of milliseconds since the board turned on — a handy stopwatch we use constantly for "has enough time passed?"

The big moment: driving a servo (our "lock")

#include <ESP32Servo.h>

Servo bolt;                  // our lock's motor
const int BUTTON = 4;

void setup() {
    bolt.attach(13);         // servo signal wire on pin 13
    pinMode(BUTTON, INPUT_PULLUP);
    bolt.write(0);           // start LOCKED (bolt at 0 degrees)
}

void loop() {
    if (digitalRead(BUTTON) == LOW) {
        bolt.write(90);      // OPEN: turn bolt to 90 degrees
        delay(2000);         // stay open 2 seconds
        bolt.write(0);       // LOCK again
    }
}

Press the button → the servo arm swings to open the latch,
waits 2 seconds, then swings back to locked. You just built
a working (if simple) door lock!

The problem with delay()

Fix #1: non-blocking timing with millis()

Instead of napping, we keep looping and just check the clock each time: "has 2 seconds passed yet? No? Fine, do other stuff and check again." Nobody freezes.

unsigned long openedAt = 0;
bool isOpen = false;

void loop() {
    // 1) React to the button instantly (no freezing).
    if (digitalRead(BUTTON) == LOW && !isOpen) {
        bolt.write(90);
        isOpen = true;
        openedAt = millis();     // remember WHEN we opened
    }

    // 2) If it's been open 2s, auto-lock — checked every loop, no delay().
    if (isOpen && millis() - openedAt > 2000) {
        bolt.write(0);
        isOpen = false;
    }

    // 3) Meanwhile the loop is free to blink a light, check Wi-Fi, etc.
}

Fix #2: a real operating system for tiny chips — FreeRTOS

// Task 1: blink a status LED forever, independently.
void blinkTask(void* param) {
    for (;;) {                                  // forever
        digitalWrite(LED, HIGH);
        vTaskDelay(500 / portTICK_PERIOD_MS);   // polite sleep, frees the CPU
        digitalWrite(LED, LOW);
        vTaskDelay(500 / portTICK_PERIOD_MS);
    }
}

void setup() {
    pinMode(LED, OUTPUT);
    // Hand the task to the controller to run on its own.
    xTaskCreate(blinkTask, "blink", 2048, nullptr, 1, nullptr);
}

void loop() {
    // This can now handle the button while the LED blinks by itself.
}

The key difference: vTaskDelay() is a polite sleep — while one task rests, the controller lets other tasks run. Unlike delay(), it doesn't freeze the whole chip.

Talking safely between tasks: queues, mutexes

Sleeping to save battery

A battery-powered lock can't run full speed 24/7 or the battery dies in a day. The ESP32 can enter deep sleep — nearly off, sipping almost no power — and wake up when the button is pressed. We'll use this so a lock can run for months on a battery.

The full multitasking circuit

Connecting to Wi-Fi

The ESP32 has Wi-Fi baked in. Joining a network is just a few lines:

#include <WiFi.h>

const char* SSID     = "MyHomeWiFi";
const char* PASSWORD = "supersecret";

void setup() {
    Serial.begin(115200);
    WiFi.begin(SSID, PASSWORD);

    // Wait until connected, printing dots.
    while (WiFi.status() != WL_CONNECTED) {
        delay(500);
        Serial.print(".");
    }
    Serial.println("\nConnected! My address is:");
    Serial.println(WiFi.localIP());   // the lock's address on your network
}

....
Connected! My address is:
192.168.1.57

How should the lock and the world talk? Meet MQTT

• Publish = post a message to a topic. (Lock posts "I'm locked" to frontdoor/status.)
• Subscribe = watch a topic. (Lock watches frontdoor/command for "OPEN".)
• Broker = the middleman server everyone connects to. (You can run one, or use a hosted one.)

#include <PubSubClient.h>   // a popular MQTT library

// This function runs whenever a message arrives on a topic we watch.
void onMessage(char* topic, byte* payload, unsigned int len) {
    std::string msg((char*)payload, len);
    if (msg == "OPEN") {
        bolt.write(90);                                 // unlock!
        client.publish("frontdoor/status", "OPEN");     // tell the world
    }
}

void setup() {
    // ...connect Wi-Fi (as above)...
    client.setServer("broker.example.com", 1883);
    client.setCallback(onMessage);
    client.subscribe("frontdoor/command");   // watch for commands
}

You (or an app) publish "OPEN" to frontdoor/command.
→ The broker delivers it to the lock.
→ onMessage() runs, the servo opens, and the lock publishes "OPEN"
  back to frontdoor/status so your app can show the new state.
You just unlocked a door from anywhere on your network.

Speaking JSON on a tiny chip

#include <ArduinoJson.h>

JsonDocument doc;
doc["door"]    = "front";
doc["state"]   = "locked";
doc["battery"] = 87;

char out[128];
serializeJson(doc, out);        // turn it into text
client.publish("frontdoor/status", out);
// sends: {"door":"front","state":"locked","battery":87}

Why the simple version from Module 8 is dangerous

1. Encrypt the channel (TLS)

In practice: connect to the broker on the secure port (usually 8883 for MQTT) using WiFiClientSecure instead of the plain client, and load the trusted certificate. Same code shape as before, just the secure version.

2. Prove who's asking (authentication)

• The lock authenticates to the broker with a username/password or, better, a client certificate unique to that device.
• Unlock commands should carry a token that proves the sender is allowed — not just the word "OPEN." Think of it as a signed permission slip the lock checks before moving.

3. Stop replay & tampering

Where to keep secrets

Passwords and keys must not sit in plain text where anyone reading the chip's memory can grab them. Options, from basic to strong:

• Store them in a protected flash area, not hard-coded in your source.
• Better: use the ESP32's built-in flash encryption and secure boot.
• Best: a dedicated secure element chip whose whole job is guarding keys.

Updating safely (OTA)

Think like an attacker (threat modeling)

Before shipping, sit down and list how someone could break in: eavesdropping on Wi-Fi, replaying commands, prying the device open, draining the battery to force a fail-open, jamming the signal. For each, decide your defense. This checklist mindset is what separates a hobby project from a product people trust on their front door.

Debugging on hardware

You can't just add console.log and refresh. Your tools on a chip:

• Serial printing — Serial.println(...) is your main window into what's happening. Print the state at key moments.
• LEDs as signals — blink patterns can tell you what stage the code reached, even with no screen.
• A hardware debugger — advanced: step through code running on the actual chip.

The watchdog: a timer that reboots a frozen chip

Surviving bad power

Real doors have flaky power: batteries dip, someone yanks a plug, voltage sags when the motor kicks in (a "brown-out"). Good firmware detects these and handles them gracefully instead of behaving randomly. The ESP32 has brown-out detection built in; you decide what happens when it fires.

The most important design question: fail-safe or fail-secure?

Testing the brain without the body

// Pure logic, no hardware — easy to test.
bool shouldOpen(bool tokenValid, bool withinTime) {
    return tokenValid && withinTime;
}

int main() {
    // tiny homemade tests
    if (shouldOpen(true,  true)  != true)  std::cout << "FAIL 1\n";
    if (shouldOpen(false, true)  != false) std::cout << "FAIL 2\n";
    if (shouldOpen(true,  false) != false) std::cout << "FAIL 3\n";
    std::cout << "All tests done.\n";
    return 0;
}

All tests done.

Later you'd use a real testing framework (like GoogleTest or Unity), but the idea is the same: keep your decision-making in plain, testable functions. Tools called static analysis and sanitizers can also scan your code for memory bugs before they ever reach a door.

The whole picture

 [React app]  ⇄  [Go backend + MQTT broker]  ⇄  [ESP32 lock]
   taps            users, rules, history,          servo,
   "Open"          sends signed commands            sensors

The backend — in Go, your strength

This is comfortable territory. Your Go server:

• Holds accounts and decides who may open which door.
• Issues the signed tokens the lock checks (from Module 9).
• Talks to the MQTT broker to send commands and receive status.
• Stores history: who opened the door and when.
• Exposes a REST or WebSocket API for the app.

The app — in React, also your strength

A dashboard that shows each lock's live state, an Open button, a history log, and user management. Live updates over WebSocket so the UI flips to "Open" the instant the door moves. You've built dashboards like this before; this one just controls physical doors.

Provisioning: the tricky new bit

Fleet management: from one lock to thousands

Selling one lock is a project; selling thousands is a business. You'll need to: push OTA updates to many devices safely, watch which locks are online, spot failing batteries, and roll out changes gradually so a bad update doesn't brick every customer at once. Start simple, but design with "many devices" in mind.

From breadboard to product (a peek ahead)

Eventually the breadboard becomes a real circuit board (PCB), the parts get an enclosure that mounts on a door, and you think about certification, weatherproofing, and manufacturing. That's a whole journey of its own — but it starts with exactly the prototype you'll have built by the end of this course.

Every milestone you've built now clicks together into a single system. Here's the checklist for a complete capstone:

The firmware (C++, Modules 1–10)

• A clean Lock class hierarchy driving a real servo or solenoid (Modules 3, 6).
• Non-blocking, multi-tasking behavior via millis() and/or FreeRTOS (Module 7).
• Auto-lock timeout and a status LED that never freezes (Module 7).
• Wi-Fi + secure MQTT, publishing status and receiving commands (Modules 8, 9).
• Token-checked, encrypted unlocks that reject replays (Module 9).
• A deliberate, tested fail-state and a watchdog (Module 10).
• Signed OTA updates so you can fix it in the field (Module 9).

The product layer (Go + React, Module 11)

• A Go backend: users, permissions, signed tokens, MQTT bridge, history log.
• A React app: live lock state, Open button, activity history, user management.
• A provisioning flow to get a new lock onto a customer's Wi-Fi.

The documentation (what makes it a product)

• A wiring diagram and photos of the build.
• A written fail-safe decision and why you chose it.
• A short threat model: how someone might attack it and how you defend.
• A README so someone else could rebuild it.

Where to go next

• Add an RFID or keypad entry method (more Actuator/sensor classes — your Module 3 design pays off).
• Add battery monitoring and deep sleep for months of runtime (Module 7).
• Move from breadboard to a custom PCB and a door-mountable enclosure.
• Read A Tour of C++ (Stroustrup) to deepen the language, and the ESP-IDF docs to go beyond Arduino-style code.
• Learn the safety standards and certifications for security hardware before you sell to real homes.