With vs. Without: An AI Coding Assistant on a Real Sensor-Driven Embedded Design

Sensor-driven embedded systems spend a disproportionate share of their engineering budget on tasks that look mundane - ADC plumbing, offset calibration, ISR state machines, zero-crossing logic, fixed-point math, and reading the right paragraph of a 2,000-page datasheet at the right moment. This article compares how these sensor-level tasks play out with and without the Microchip MPLAB AI Coding Assistant, using a reference-design-class development platform as the benchmark: a bidirectional totem-pole Power Factor Correction (PFC) stage built around a dsPIC33CH dual-core digital signal controller. The result is not that the assistant replaces the embedded engineer - it is that it reliably removes a large share of the manual drudgery around the sensor chain, letting the engineer spend that time on the parts that actually require engineering judgement.

1. The Benchmark Design

The benchmark platform used for this comparison is a bridgeless totem-pole PFC demonstration design with isolated AC-voltage acquisition, current-sense signals sampled by the dsPIC33CH ADC, and a software zero-cross detector. In the three-channel control framework shown in the reference material, those signals feed three 2p2z current loops at 100 kHz and one voltage loop at 300 Hz. From a firmware perspective, this is a sensor-heavy system:

• The isolated voltage-acquisition board transfers V_AC data to the main power board over SPI on a 100 kHz acquisition/control cadence, with an ADC offset-calibration state machine that runs before the online state.

• A software zero-crossing detector with symmetric hysteresis runs every switching period and drives the half-bridge gate remap.

• Three current-sensing channels are fed into 2p2z compensators whose coefficients come out of Microchip's Digital Compensator Design Tool (DCDT).

• A DC-bus monitor provides V_BUS over-voltage checking and the adaptive step-response fast path.

Each of these is a textbook sensor-subsystem task. Each was implemented twice - once using the traditional toolchain (datasheet, MCC/Melody, hand-coded state machines) and once using the Microchip MPLAB AI Coding Assistant on top of the same toolchain. The numbers below are indicative effort for an engineer who is already fluent with dsPIC33CH and MPLAB X.

2. Task A - Isolated V_AC Acquisition Board: ADC + SPI + Offset Calibration

Without the assistant. The engineer opens MCC, configures the ADC channels and the SPI slave peripheral, exports the code, then hand-writes the offset-measurement state machine, the per-channel averaging, the checksum, and the STATE_OFFSET_MEAS → STATE_ONLINE transition. The hardest part is not writing it; the hardest part is getting the trigger-to-SPI-to-control timing aligned with the 100 kHz control cadence: the acquisition is triggered at the beginning of the cycle, SPI starts a few microseconds later, the primary-core V_AC monitor completes before the data is passed to the secondary core, and the secondary-core ISR uses that data on the next 20 µs boundary shown in the timing slide. Typical time budget: ~1 working day, including one or two scope sessions.

With the Microchip MPLAB AI Coding Assistant. The engineer prompts:

"Generate a state machine for an isolated acquisition board running on a PIC with three ADC channels plus SPI slave output. States: OFFSET_MEAS (average a configurable number of samples per channel, verify tolerance, transmit offsets over SPI, then switch to ONLINE), ONLINE (on external trigger: sample 3 channels, subtract per-channel offset, compute a checksum, transmit 4×16-bit words over SPI). Target: 100 kHz acquisition cadence."

The assistant returns a compilable skeleton aligned with the documented flow, including the tolerance check, the checksum path, and the STATE_OFFSET_MEAS to STATE_ONLINE transition. A follow-up prompt can add missed-trigger protection around the same 100 kHz trigger cadence. Time budget: ~2 hours, most of it spent on scope verification, not typing.

3. Task B - Zero-Cross Detection at 100 kHz

Without the assistant. Zero-cross sounds easy until you implement it. The naïve comparator-against-zero approach chatters because of noise and THD; the textbook solution is a two-threshold hysteretic detector combined with a slope sign. Getting the four states (entering/exiting region × positive/negative slope) right usually takes a whiteboard, a notebook, and half a day of bench debug to discover the single edge case that only appears near very low line voltages.

With the assistant. Prompt:

"Write a C function called every 10 µs that takes a signed 16-bit AC-voltage sample and produces: (a) polarity flag, (b) in-zero-cross-region flag with ±V_ZC_TH hysteresis, (c) an `soft_start_armed` flag that arms once per half-cycle when leaving the ZC band. Must be branchless where possible for deterministic ISR latency."

The generated code passes review; the only human change is tuning V_ZC_TH to the actual transformer and gating the logic with the V_AC OK conditions used by the monitor: V_AC not under- or over-voltage, line frequency between 45 Hz and 65 Hz, and stability for 10 AC line cycles. Time budget: ~30 minutes vs. half a day.

4. Task C - 2p2z Compensator from DCDT Coefficients

Without the assistant. DCDT produces B₀/B₁/B₂/A₁/A₂ coefficients and a reference implementation. The engineer must then integrate them into the secondary-core ISR, add the adaptive gain branch that scales the B-terms below a load threshold, add the duty-ratio feed-forward term D = (V_OUT − V_IN)/V_OUT, and make sure the current-loop work fits inside the 10 µs ADC ISR. The reference material quotes roughly 660 ns execution time for one optimized 2p2z compensator, so the remaining ISR tasks still have to be budgeted carefully. Typical time: ~1 day plus oscilloscope and THD-analyzer bench time.

With the assistant. Prompt:

"Integrate the attached DCDT coefficients into a 2p2z current compensator. Add: (1) adaptive gain that uses the voltage-loop output as a load proxy and scales the B-coefficients when V_loop_out < 16000, clamped at 3276; (2) duty-ratio feed-forward using V_BUS and V_AC; (3) output saturation at min/max duty; (4) dsPIC33CH-optimized fixed-point arithmetic. Provide a small test harness and an execution-time check for the ISR path."

The assistant emits the compensator structure, the #define ADAPTIVE_GAIN_ENABLED guard, and a timing check that can be used during bench validation. On the bench data shown for the reference design, THDᵢ measured at a 40 W electronic load was 3.25 % with duty-ratio feed-forward vs. 4.25 % without, which is the target behaviour the generated integration has to preserve. Time budget: ~3 hours.

5. Task D - Datasheet and Reference Design Lookup

An often-ignored category. Across the three tasks above, the engineer referenced the dsPIC33CH datasheet and reference material for ADC timing, PWM trigger sources, SPI timing, core-to-core handoff, fixed-point arithmetic, and the errata. Without the assistant, this is classical PDF navigation — probably 30–45 minutes of cumulative reading per task.

With the assistant connected to Microchip's internal documentation services (datasheets, EVK user guides, compiler manual, MUSL standard-C-library guide, release notes), those lookups return as short, citable answers inside the chat, and are threaded directly into the generated code as comments. Cumulative reading time: under 10 minutes per task.

6. What Still Belongs to the Engineer

The comparison is favourable to the assistant, but the picture is not "AI writes the firmware." Three classes of decisions must still come from the human:

1. Safety-Critical and Regulatory Logic: Over-voltage trip thresholds, soft-start sequencing, and the AC_OK validation window are derived from specifications that the assistant cannot own.

2. Bench validation: THD, reverse-recovery losses, and EMC margins are measured, not generated. The assistant accelerates the path to the bench, not the bench itself.

3. System-Level Architecture: Choosing a dual-core dsPIC33CH rather than a single-core device, putting the sensing on an isolated board, or serialising data digitally rather than analog — these are the design decisions that set the performance ceiling, and they remain firmly with the engineer.

7. Takeaway

In a sensor-heavy embedded design, the engineer's calendar typically looks like: 20% architecture, 60% peripheral plumbing and calibration code, 20% bench verification. The Microchip AI Coding Assistant compresses the middle block without inflating the ends. On the totem-pole PFC reference-design platform, the sensor-subsystem implementation work above shrank from roughly three working days of manual implementation and lookup effort to about one working day with the assistant, while the design targets and bench reference points remained the same: 98.5% efficiency as a key specification, 3.25% THDᵢ with duty-ratio feed-forward in the 40 W measurement shown, and IEC/EN 61000-3-2 compliance in the reference measurement.

For teams building the next generation of sensor-driven converters, chargers and inverters, that is not a marginal improvement. It is the difference between shipping the sensor subsystem on schedule and watching it eat the schedule.

Franziska Kofler holds a B.Eng. in Electrical and Information Engineering and an M.Eng. in AI for Autonomous Systems. After working in embedded software development, she joined Microchip as a Field Applications Engineer (FAE), where she supports customers in developing innovative embedded and AI-based solutions. In her free time, she is active in a local shooting club and regularly works out at the gym.