● Open to workPune, INRev. 2026

§01 — Embedded systems engineer

Kandarp
Vaidya

From logic gates to networked products, I work every layer in between: Linux kernel drivers, signed bootloaders, MCU firmware, robotics, and the debugging that ties it together.

Descend the stack ↓Get in touch

Fig. 1 — Exploded view, rev A

scroll to explode

Loading board…

sustained IIO capture, 0 dropped samples
3.2 kHz
signed bare-metal bootloader
9.7 KB
simulated power cuts per update, always recovered
585–778
granted Indian design patents (2026)
4

§02 — Width × depth

Every layer
of the stack

pick a layer, or just keep scrolling ↓

Most engineers live on one layer. Embedded work punishes that: a dark LED panel can be an init-order bug, a missing kernel module, or a gear that doesn't mesh. Below, each layer comes with something you can poke, and what I've actually built there.

  1. L0Gates
  2. L1Registers
  3. L2Firmware & drivers
  4. L3Operating systems
  5. L4Buses & networks
  6. L5Systems & products

Layer 0 of 5

Gates

ECE fundamentals, all the way down: one NAND gate, then the four transistors inside it. Flip the inputs and watch both views agree.

go on, poke A and B ↓

Truth table · 2-input NAND
ABY
001
011
101
110

A is 1, B is 0, output Y is 1.

  • NOT1 NAND, inputs tied
  • AND2 NANDs
  • OR3 NANDs
  • XOR4 NANDs
Fig. 2a — Gate view
ABYNAND
Fig. 2b — CMOS view · 4 transistors
PAPBNANBVDDGNDABABYPA conducts → Y pulled to VDD

Layer 1 of 5

Registers

Where software stops being abstract. Every feature is a bit in a register, and the datasheet is the source of truth. Click the bits of a real ADXL345 register.

this is literally what my driver writes ↓

Fig. 3 — ADXL345 register explorer

BW_RATE @ 0x2C
0x0F
0b00001111
  • Output data rate 3200 Hz · bandwidth 1600 Hz
  • Normal power mode
  • ↳ the rate my IIO driver sustained with 0 dropped samples
On the wire (I2C write to 0x53)
S 0xA6 addr+W A 0x2C reg A 0x0F data A P 
/* in the kernel driver */
regmap_write(st->regmap, ADXL345_REG_BW_RATE, 0x0F);

Fig. 4 — Register level, STM32 side

The last thing my bootloader does after verifying a signature: point the vector table at the app, load its stack pointer, and jump. No HAL, just addresses.

/* bootloader → verified app (simplified) */
uint32_t sp = *(volatile uint32_t *)APP_BASE;
uint32_t pc = *(volatile uint32_t *)(APP_BASE + 4);
*(volatile uint32_t *)0xE000ED08 = APP_BASE; /* SCB->VTOR */
__asm volatile("msr msp, %0" :: "r"(sp));
((void (*)(void))pc)();               /* never returns */
  • Own linker scripts
    flash split into bootloader + A/B slots
  • Own startup code
    vector table, .data/.bss init
  • UART, flash, timer drivers
    written against the reference manual
  • regmap + devm
    register I/O on the Linux side

Layer 2 of 5

Firmware & drivers

The two builds I'd defend to anyone, specced like a datasheet. Every value below was measured or tested, not estimated.

every value measured, not guessed ↓

01 · EMBEDDED LINUXPI 5 · ADXL345

Interrupt-driven Linux IIO driver

Out-of-tree I2C kernel driver in C: regmap, devm resources, a threaded IRQ, a data-ready IIO trigger and a triggered buffer with kernel timestamps, bound through a device-tree overlay. Benchmarked against user-space polling with Python capture tools.

ParameterValueCondition
Sustained rate3.2 kHz0 dropped, 400 kHz I2C
Polling peak~2.3 kHzuser-space baseline
CPU / sample−57 to −62%vs polling
Long capture470,00010 min @ 800 Hz, no gaps
Image size185 MBBuildroot, loads at boot
Stylecleancheckpatch --strict
View source on GitHub ↗
02 · BARE METALSTM32F401RE

Signed, rollback-safe bootloader

No-HAL C with its own linker scripts, startup code and drivers. A/B update with backup, trial boot, self-confirmation and automatic rollback. A Python board simulator cuts power at every flash operation; a C# (.NET) update tool is tested against it.

ParameterValueCondition
Footprint9.7 KBno HAL, own startup + linker
SignatureECDSA P-256+ SHA-256, after transfer & every boot
TransportUARTCRC-32 framed protocol
Flag states64 / 64decision logic unit-tested
Power cuts585–778per update, simulated
Recoveryalwaysunit + simulator tests in CI
View source on GitHub ↗

Fig. 5 — Pull the plug: A/B update, live

Try to brick it.

hit ⚡ at any moment. it always comes back.

  1. 01ReceiveCRC-32 framed UART
  2. 02VerifySHA-256 + ECDSA P-256
  3. 03Mark trialwrite-once flag
  4. 04Rebootrelocate VTOR, jump
  5. 05Trial boottimer running
  6. 06Confirmapp self-confirms
SLOT A—
—
SLOT B—
—
UART console
boot: slot A v1.0 confirmed · signature OK
boot: jumping to slot A

Simplified model for the browser. The real decision logic is a write-once flash-flag state machine, unit-tested across all 64 flag states, plus a simulator that cuts power at every one of 585–778 flash operations per update.

Layer 3 of 5

Operating systems

Linux when the job needs a kernel, FreeRTOS when it needs a scheduler, bare metal when it needs neither. Here's the path one accelerometer sample takes through my driver.

one sample, hardware → kernel → you ↓

Fig. 6 — IIO triggered-buffer data path

HardwareKernel spaceUser space
  1. 01ADXL345INT1 · data ready
  2. 02Hard IRQiio_trigger_poll()
  3. 03Threaded handlerregmap_bulk_read() · 6 B
  4. 04IIO buffersample + kernel timestamp
  5. 05/dev/iio:device0character device
  6. 06Python capturebenchmarks, logging

Fig. 7 — Interrupts vs polling (measured)

Sustained sample ratehigher is better
IIO driver
3.2 kHz
Polling
~2.3 kHz
CPU time per samplelower is better
Polling
baseline
IIO driver
−57–62%

400 kHz I2C, Raspberry Pi 5. Zero dropped samples at 3.2 kHz; a 10-minute run at 800 Hz captured 470,000 samples with no gaps.

  • LINUX · BUILDROOT

    185 MB cross-compiled image

    Minimal image that loads the driver at boot by modalias.

  • LINUX · DEVICE TREE

    Overlay-bound driver

    Device described in an overlay, probed on the Pi 5's I2C bus.

  • FREERTOS · ESP32

    ESP32 core 3.x

    Ported an AVR P10 LED-matrix driver to ESP32 with PWM brightness.

  • BARE METAL · CORTEX-M4

    No OS at all

    The bootloader runs before anything else exists: no RTOS, no HAL.

Layer 4 of 5

Buses & networks

Chips talk over buses, boards talk over networks. Debugging either means seeing the actual bits, which is why the scope comes out first.

my Pi knocking on the ADXL345's door ↓

Fig. 8 — I2C write to 0x53 @ 400 kHzCH1 SCL · CH2 SDA
SCLSDA10100110ACKSTARTaddress 0x53 + writeSTOP

↑ that dip on SDA = the sensor saying "yep, I'm here"

  • UART

    Async serial. My bootloader’s CRC-32 framed update channel.

  • I2C

    Two wires, addressed, ACKed. The ADXL345 link at 400 kHz.

  • SPI

    Clocked, full-duplex, chip-select. LED matrices and fast peripherals.

  • MQTT

    Publish / subscribe over TCP. Small devices, shared topics.

  • ZeroMQ

    Brokerless message sockets between processes and boards.

  • Wi-Fi / BLE

    The ESP32 radio. Where a board becomes a node.

Fig. 9 — From a board to a system

A room that knows you're there.

At PHN I drafted the architecture for a distributed, multi-sensor presence system: a ceiling sensor hub, a Raspberry Pi HMI, and ESP32 relay and power-meter nodes. I defined 35 features with multi-sensor fusion, selected the hardware and drafted the BoM.

packets in flight →

LOCALNETWORKCeiling sensor hubmulti-sensor fusionRaspberry Pi HMIdisplay + controlESP32 relay nodeswitching loadsESP32 power metermeasuring loads

Layer 5 of 5

Systems & products

The top of the stack: deciding what to build, what it's made of, and whether a stranger could use it. This is where patents and test rigs live.

the boring bits that make it shippable ↓

Granted · 2026

4 Indian design patents

Granted for IoT and solar product designs.

DESIGN 01

IoT / solar

GRANTED

DESIGN 02

IoT / solar

GRANTED

DESIGN 03

IoT / solar

GRANTED

DESIGN 04

IoT / solar

GRANTED

Taipei · 2026

COMPU
TEX

Presented my embedded projects to Acer's Taipei R&D team.

Test automation · PHN

60+sensors

One automated validation rig

Electrical and response-level pass/fail tests, cutting validation time by about 80%.

System architecture · PHN

35features defined

Distributed presence system

Multi-sensor fusion across a ceiling hub, Pi HMI and ESP32 nodes. Hardware selected, BoM drafted.

On the bench now · in progress

ESP32 AC power meter, V1

My own project: taking an ESP32 power-meter schematic toward a compact, safe, manufacturable V1, in phases: design audit, requirements, circuit redesign, PCB and enclosure, firmware, validation.

mains voltage: treated with respect

§03 — Debug log

How I find
what's broken

symptom → ruled out → root cause → fix

  1. DBG-01ESP32 · FreeRTOS · SPI

    The LED matrix that went dark

    Symptom

    After porting a P10 LED matrix driver from AVR to ESP32 (core 3.x), the panel stayed dark.

    Ruled out

    • ✕Logic-level mismatch
    • ✕SPI timing

    Root cause

    Init order: configuring the GPIOs after starting VSPI detached the pins from the SPI peripheral.

    Fix

    Reordered initialisation, then added PWM-on-OE brightness control (0–100%).

  2. DBG-02Linux · Buildroot · I2C

    Driver never bound at boot

    Symptom

    In the minimal Buildroot image, the driver failed to bind to the ADXL345.

    Root cause

    The I2C controller module was not loading, so there was no bus for the device to appear on.

    Fix

    Got the controller module loading at boot; the driver now autoloads by modalias.

  3. DBG-03Python · simulation · host tools

    The simulator caught my own tool

    Symptom

    The power-cut simulator flagged a failure during an update run.

    Root cause

    A bug in the host-side update tool, not in the firmware.

    Fix

    Fixed the host tool; the simulator now runs in CI so it stays caught.

  4. DBG-04Mechanics · CNC plotter

    Wobbly lines on a CNC plotter

    Symptom

    Plotted output showed motion artifacts.

    Root cause

    Mechanical tolerance and gear-meshing faults.

    Fix

    Iterative 3D-printed part revisions until the artifacts were gone.

  5. the scope is usually right.
    the assumption usually isn't.

    Tools: oscilloscope · multimeter · OpenOCD · simulators · checkpatch · pytest

§04 — The bench

Width: robots,
rigs & side quests

35+ projects and counting

Robotics · closed-loop control

Robots that hold a line

A self-leveling platform plus line-following and wall-following robots: sense, decide, actuate, repeat, with PWM motor and servo control underneath.

  • Self-leveling
  • Line-follow
  • Wall-follow

Mechanics · debug

CNC plotter

Root-caused motion artifacts to tolerance and gear-meshing faults; fixed with iterative 3D-printed part revisions.

Aerial · PHN

Smart Quad Drone

Worked on PHN Technology's quadcopter kit.

Breadth · 2025

35+ embedded builds

Digital and ADC sensor interfacing, PWM motor and servo control, SPI, I2C and UART.

Display · ESP32

P10 LED matrix

AVR → ESP32 port with 0–100% PWM-on-OE brightness. See DBG-01.

Parts drawer

datasheets read at 2 am

U2LGA-14

ADXL345

3-axis accel · I2C

U5MODULE

Ultrasonic

40 kHz echo

M1PWM

Servo

50 Hz frame

U3WROOM

ESP32

Wi-Fi · BLE

S1DIGITAL

PIR sensor

presence · motion

D15 MM

The LED

where it all starts

§05 — Pinout

Toolbox, as
a datasheet

41 pins, all connected

Languages

  • 1C
  • 2Embedded C
  • 3C++
  • 4Python
  • 5C# (.NET)

Embedded

  • 6Bare-metal
  • 7FreeRTOS
  • 8Interrupts
  • 9Timers
  • 10PWM
  • 11ADC
  • 12GPIO
  • 13Bootloaders
  • 14Firmware update

Embedded Linux

  • 15Kernel drivers
  • 16IIO
  • 17regmap
  • 18IRQs
  • 19Device-tree overlays
  • 20Buildroot
  • 21Cross-compilation

KV-01

Embedded systems
engineer

IIIT SURAT · ECE · 2025
REV 2026 · PUNE

Buses & networks

  • 41UART
  • 40I2C
  • 39SPI
  • 38MQTT
  • 37ZeroMQ

MCUs & boards

  • 36STM32 (Cortex-M)
  • 35ESP32
  • 34ATmega328P
  • 33Raspberry Pi

Toolchain & debug

  • 32arm-none-eabi-gcc
  • 31OpenOCD
  • 30Make
  • 29Git
  • 28GitHub Actions
  • 27pytest
  • 26checkpatch

Bench

  • 25Oscilloscope
  • 24Multimeter
  • 23KiCad
  • 223D printing

§06 — Changelog

Release notes

semver for a career

  1. v0.1 · 2021

    B.Tech, Electronics & Communication

    IIIT Surat

    Graduated 2025 · CGPA 7.8/10

  2. v1.0 · Jan 2025

    R&D Intern

    PHN Technology, Pune

    35+ embedded projects, 60+ sensor validation rig

  3. v2.0 · Aug 2025

    Embedded Systems Engineer, R&D

    PHN Technology, Pune

    ESP32 drivers, system architecture, debugging

  4. v3.0 · 2026

    4 Indian design patents granted

    IoT & solar product designs

  5. v4.0 · 2026

    Presented at COMPUTEX

    To Acer's Taipei R&D team

  6. v5.0 · 2026

    Linux IIO driver + signed STM32 bootloader

    Solo projects, open source

    Measured, tested, in CI

§07 — Ship to

handle with care: kettle's on

Let's build
something solid

Open to embedded, firmware and embedded-Linux roles. If your product has a microcontroller in it, I'd like to hear about it.

kandarpvaidya03@gmail.com
GitHub ↗Résumé.pdf ↓
FROM
Kandarp Vaidya · Pune, India
CONTENTS
1× embedded systems engineer
CONDITION
tested, measured, signed
HANDLING
gates → registers → drivers → OS → networks → products
RAYFOLD.COM · 2026