Clock-Dependent Peripheral Design

Question

Problem: Clock-Dependent Peripheral Design. Solve this hands-on electronics task on EWskills.

Accepted Answer

#include 
using namespace std;

class ClockController {
public:
    ClockController() {
        cout << "Clock enabled" << endl;
    }

    ~ClockController() {
        cout << "Clock disabled" << endl;
    }

    void write(int offset, int value) {
        cout << "Clocked write: " << offset << " " << value << endl;
    }
};

class Peripheral {
private:
    ClockController& clk;

public:
    Peripheral(ClockController& c) : clk(c) {
        cout << "Peripheral ready" << endl;
    }

    ~Peripheral() {
        cout << "Peripheral stopped" << endl;
    }

    void writeReg(int offset, int value) {
        clk.write(offset, value);
    }
};

class Driver {
private:
    ClockController clk;
    Peripheral periph;

public:
    Driver() : periph(clk) {
        cout << "Driver started" << endl;
    }

    void operate(int offset, int value) {
        periph.writeReg(offset, value);
    }

    ~Driver() {
        cout << "Driver stopped" << endl;
    }
};

int main() {
    int offset, value;
    cin >> offset >> value;

    {
        Driver drv;
        drv.operate(offset, value);
    }

    return 0;
}

Explanation & Logic Summary:

This problem demonstrates dependency-aware composition, where one component cannot function unless another component is already active.

The Driver owns the ClockController, making it responsible for enabling and disabling the clock.
The Peripheral does not own the clock; instead, it depends on an existing clock instance via a reference.

Because references:

Must be initialized at construction
Cannot be null
Cannot be reseated

the following guarantees are enforced:

The peripheral cannot exist without a clock
The clock must be created before the peripheral
The peripheral can never use an invalid clock

Constructor order guarantees safe startup:

Clock enabled
Peripheral ready
Driver started

Destructor order guarantees safe shutdown:

Driver stopped
Peripheral stopped
Clock disabled

Firmware Relevance & Real-World Context:

On real microcontrollers, peripherals such as UART, SPI, I2C, timers, and ADCs require their clocks to be enabled before any register access.

Violating this rule can cause:

Ignored writes
Bus faults
System lockups or resets

By encoding hardware dependencies directly into C++ class relationships:

Invalid states become impossible to express
Initialization and shutdown order is deterministic
Entire classes of low-level firmware bugs are eliminated

This makes dependency-aware composition a core embedded C++ design skill.

Ownership Type	Concept	C++ Tool
Owner	"I control this life. When I die, it dies."	`std::unique_ptr` or Member Variable.
Shared Owner	"We keep this alive as long as one of us needs it."	`std::shared_ptr`.
Observer	"I just look at it. I hope it's still there."	Raw Pointer (`T*`) or Reference (`T&`).

Pitfall	Details
❌ Deep Inheritance	Avoid creating 5-layer deep class hierarchies (`Driver -> Serial -> UART -> STM32_UART`). It increases code size (v-tables) and makes debugging a nightmare. Prefer Composition.
❌ Raw Pointers as Owners	Never use a raw pointer (`T*`) to own data. `drivers.add(new UART());` is a leak waiting to happen. Use `unique_ptr` for ownership, raw pointers only for observing.
❌ Circular Dependency	If Object A owns B, and Object B owns A (via `shared_ptr`), they will keep each other alive forever (Memory Leak). Use `weak_ptr` or raw references to break the cycle.
✅ Dependency Injection	Pass the "Sub-components" into the Constructor rather than creating them inside. `Motor(PWM& pwm)` is better than creating a `new PWM` inside `Motor`, because it allows you to pass a `MockPWM` for testing.

126. Clock-Dependent Peripheral Design

Syntax & Usage

Ownership Model

Relevance in Embedded/Firmware

Common Pitfalls (Practical Tips)