Leading a 20-person controls & firmware team on a Formula SAE electric race car

I lead the group behind the car's electronics: ECU architecture, telemetry, HIL/SIL test infrastructure, and vehicle control logic. My focus this year has been making the firmware testable so we can improve code coverage and catch bugs before they reach the car.

Our hardware-abstraction layer had grown so broad that it worked against us: the old idea was that all code should be platform-agnostic, which pushed IO so far from the application that we couldn't use STM32 timers or interrupts where we needed them. I rescoped it so SIL tests one task at a time, sitting between unit tests and HIL, rather than mocking the whole system at once.

A task takes abstract peripheral interfaces; STM32 and SIL each supply their own implementation.

The old pattern had tasks reach out to global bindings:: peripherals directly, tying every task to one board and making it impossible to substitute mocks for SIL. I moved the boundary to dependency injection: a task takes its peripherals and shared resources as arguments, so the same code runs on the STM32 with real drivers or in a SIL binary with mocks.

// BEFORE — task reaches for global bindings, hard-wired to one board
void task_10hz() {
    float v1 = bindings::suspension_travel1.ReadVoltage();  // global
    bindings::veh_can.Send(TxSuspensionTravel12{...});         // global
}

// AFTER — dependencies injected; runs on STM32 or in SIL  (racecar #529)
void ReadAndSendTemperatures(float update_period_ms, VehBus& veh_can_bus,
        FanController& fan_controller,
        etl::array<TempSensor, kSensorCount>& temp_sensors);

I built a Raspberry Pi-based system that turns live CAN traffic into usable telemetry during testing while keeping a complete local record on an SSD.

CAN frames flow through DBC decoding, local storage, InfluxDB, and Grafana.

• Decodes vehicle and powertrain messages using our DBC files, including speed, pedal position, suspension travel, motor speed, inverter temperatures, battery data, IMU measurements, and system faults.
• Streams selected signals and threshold-based alerts to InfluxDB for live Grafana dashboards.
• Records decoded data continuously to the local SSD, preserving a reliable dataset if the wireless connection drops.
• The Pi hosts its own Wi-Fi network, providing dashboard access within range without relying on external network infrastructure.

Dashboard views for live vehicle signals and fault monitoring.

Currently building. Reflashing an ECU used to mean physically reaching a board buried in the chassis and connecting a programmer. I'm building an over-the-air path instead: a Raspberry Pi pushes firmware to any ECU over the CAN bus the car already runs.

A resident bootloader on each ECU receives the image over CAN and reflashes the app in place.

• Each STM32 ECU carries a resident bootloader that writes the received image to the app flash region.
• ECUs are addressed individually on the bus, and each image is CRC-verified before the ECU jumps to the new app.

In progress. SIL proves the logic; HIL proves the firmware on real hardware. I'm writing controller sequences that run the ECUs against simulated vehicle IO on our HIL rig, so we validate behaviour before anything touches the car.

Developing firmware for automated testing and designing analog circuitry for optical hardware, Ottawa ON

My work centred on validating hardware faster. I built a menu-driven ATE framework that follows a board from prototype through production: my firmware runs on a Raspberry Pi and drives a test board that plugs into a machine exercising the real production boards.

• Wrote the I2C, SPI, and PCIe drivers the framework relied on, and validated them on the bench with an oscilloscope and logic analyzer.
• Designed and validated a dedicated fan-tachometer measurement circuit that produced more accurate RPM readings than software pulse counting on the Raspberry Pi.
• Delivered a schematic and layout uprev of an analog control board in Cadence to close out existing design issues.

Fan-RPM test fixture used to validate the dedicated tachometer measurement circuit.

Pi-hosted firmware drives a test board connected to the hardware under test.

Firmware and real-time tooling for a digital instrument, Toronto ON

A faulty hall-effect sensor or a misaligned assembly could pass initial checks and only fail later in QA. I wanted those caught the moment a unit was built, so I wrote a C test sequence that streams live sensor data straight to the assembler.

• The sequence runs on the BeagleBone, continuously polling the hall-effect sensor ADCs and pushing readings into a real-time Matplotlib view.
• Watching the live signal, an assembler can spot a weak sensor or a bad mechanical fit on the spot, with no manual log review.
• Used during hardware bring-up to surface faulty readings quickly and cut time spent on QA and calibration.

Live hall-effect sensor readout used on the assembly line.

Personal project, STM32 hardware and firmware

I designed my own adapter end to end, board and firmware, and owned the full bring-up loop

• STM32-based PCB in Altium with USB-C, a CAN transceiver, power regulation, switchable termination, and ESD protection.
• Embedded C firmware for USB/CAN communication with configurable message filtering.
• Hardware debug and programming interfaces (SWD, status indicators) built in for bring-up.

Assembled STM32-based USB-to-CAN adapter board (Altium).

Schematic: USB-C, CAN transceiver with switchable termination, power regulation, and header.

STM32 firmware, Formula Electric vehicle

The LV BMS sits in the car's safety chain: it monitors cell voltages and enforces the constraints that decide whether the vehicle can run. Because it's safety-critical, I built the firmware around defensive, deterministic behaviour rather than clever features.

• The board talks to the battery-monitoring hardware over SPI, which offers no corruption protection, so I put a CRC / Packet Error Code (PEC) on every frame.
• Incoming frames are validated by recomputing the CRC against the received PEC, and any mismatch is rejected before it reaches safety-critical logic.
• Protocol, command codes, and application logic live in separate modules, keeping the system straightforward to debug and extend.

LV Controller to LV BMS over SPI; LV BMS to LV Battery through an ISOSPI transceiver.