Representative results only · all C code here is synthetic · no TI code is included or displayed details
Results are representative and informational only. Under Texas Instruments' C2000 software license terms, real TI SDK source code is confidential and licensed for internal use only, so no TI code is included, displayed, processed, or emitted here. All C code on this site is synthetic, written for this demo, with invented names and values that resemble typical power-converter firmware. The generated headers compile against this demo's sample firmware in CI; the "legacy" files used for the audit are illustrative and not guaranteed to compile on any target. Product ratings come from public IntelliPower data sheets; all circuit values and gains are invented. Independent demo, not affiliated with or endorsed by AMETEK, IntelliPower, or Texas Instruments. TI, C2000, and Code Composer Studio are trademarks of Texas Instruments.
Tim Otholt
Who built this demo, why an internship, and the bet it makes about the problem.
I wrote C firmware and BIOS code at Phoenix Technologies, Quantum, AMD, and VM Labs, where constants had to be exactly right for each specific board. I've come back to engineering through an A.A.S. in AI Software Engineering, and this posting described a problem I recognized: numbers hand-edited in C source that should come from the spec. I built this demo to understand the problem as well as I could from the outside, and to show how I would approach it.
I wrote firmware and BIOS code from 1988 to 2001, then spent twenty years in film and live production. To rebuild my engineering career I went back to school: I completed Per Scholas's full-stack software engineering course in 2024 (3.8 GPA), and I'm now working toward an A.A.S. in AI Software Engineering (4.0 GPA) as the first step toward a B.S. An internship is the honest way back in. The fundamentals still apply: bringing up new boards, getting each board's constants exactly right, and debugging with scopes and emulators. But TI's C2000 parts, today's toolchains, and power electronics are new to me. I'd rather learn them inside a team that ships real products, while contributing the automation and AI tooling this role describes. The demo I built is a sample of how I'd work.
IntelliPower publicly describes configure-to-order variants built from shared designs, and its engineering postings mention keeping legacy boards alive with alternate components. Every variant's ratings and every board's measurement chain must end up as correct constants in firmware; I assume much of that is done by hand today, from data sheets that aren't always consistent (all three transcribed here, AI-drafted and checked by the consistency gate, contain an inconsistency). The right tool makes that path deterministic, traceable, and gated. AI belongs only where the input is messy: here it drafts what each legacy constant is, and a person reviews every draft. Measured on a 33-constant synthetic set against a blind answer key, a low-cost model (gpt-5.4-nano) maps constants to the right rule 99% of the time but its category labels reach only 83%, below the bar I set in advance, and I report that rather than move the bar. AI never writes firmware.