Your Schematic PDF Is Version-Untracked. Your Firmware Pays the Price.
By the CADPreview Team · Series: Hardware Visibility
"The wait isn't usually about hardware being slow. It's about design being invisible."
You're mid-sprint. You've been writing the SPI driver for a week. The board lands on your desk. You flash it. Nothing works. You pull up the schematic, not the one you've been working from but the current one, the one someone exported and dropped in Slack, and there it is. The SPI bus moved. CS is on a different GPIO. The peripheral is a different variant with a different register layout.
Nobody withheld this information. The hardware engineer didn't make a mistake. The change was made on a Tuesday while you were head-down on something else.
The failure was not technical. It was a visibility failure. And it will happen again on the next project unless the underlying cause is fixed.
Why This Keeps Happening
Hardware design lives in a desktop EDA tool that almost nobody on the team can open. So information escapes the same way it has for twenty years: manually. Someone generates a PDF. Someone screenshots the GPIO table and pastes it into Slack. That export is always an afterthought, always slightly stale, and always arriving after the firmware engineer has already made assumptions based on the previous one.
This is the structural cause. Not carelessness. Not poor communication. A tool boundary that turns every design update into a manual handoff step.
The Wrong Fixes
Most teams respond with more meetings, more "please keep me posted" messages, and shared spreadsheets nobody quite trusts. These add load to the hardware engineer without removing the underlying gap. The firmware engineer still does not have access to the actual source of truth.
The Actual Fix: Parallel Design, Not Sequential Handoff
The implicit model is: hardware finishes, then firmware starts. Both need to be moving at the same time, and that means firmware needs read access to the live design, not just finished artefacts.
The conversation happens in parallel. I'm finishing the PSU design, can you check the processor GPIO assignments before I move on to layout? Firmware reviews the schematic as it is being drawn. Catches a conflict. The fix takes ten minutes. The same fix, discovered during bring-up on a physical board, takes days.
That parallel working model only functions if firmware can see the design without depending on hardware to export something for them.
Branches and Releases as a Shared Language
Firmware engineers already think in branches and releases. Hardware, on a version-controlled KiCad project, works the same way. A branch is work in progress. A release is the fabrication revision your firmware is targeting.
The problem has always been access. Viewing a KiCad branch requires KiCad installed and configured. CADPreview removes that barrier. Connect the GitHub repository once and anyone on the team can view any branch or tagged release in a browser, without installing anything. Firmware can check GPIO assignments on a branch that has not even been merged yet. Not from a PDF. From the actual source, at the revision they care about.
The PDF Is the Problem Formalised Into a Habit
The schematic PDF dropped into Slack feels like a solution. It is version-untracked. It is stale by design. The moment it is exported, it begins to diverge from the source. By the time it matters, nobody is confident which revision it represents or whether it includes that last-minute change.
The fix is not a better PDF workflow. It is eliminating the export step by giving the team access to the source.
What Changes
Firmware stops waiting for hardware to finish. Hardware stops fielding interruption requests. The project manager has a single URL showing the current state of the design, without asking anyone to generate a report. The GPIO question gets asked and answered before layout is finalised, not during bring-up.
The interface between the two disciplines is visible, current, and accessible to everyone involved.
CADPreview is a web-based viewer for KiCad projects hosted on GitHub. Connect your repository once, share a link, and your whole team sees the current schematic, layout, and BOM in a browser, on any branch, at any release, without installing anything.