Launch HN: Embedder (YC S25) – Claude code for embedded software
Here’s a demo in which we integrate a magnetometer for the Pebble 2 Duo smartwatch: https://www.youtube.com/watch?v=WOpAfeiFQkQ
We were frustrated by the gap between coding agents and the realities of writing firmware. We'd ask Cursor to, say, write an I2C driver for a new sensor on an STM32, and it would confidently spit out code that used non-existent registers or HAL functions from the wrong chip family. It had no context, so it would just guess and the code is always wrong.
Even when it wrote the right code, the agent had no way of interacting with your board and the developer would have to manually test it and prompt the agent again to fix any bugs they found. Making current solutions not ideal when working in an embedded context.
That’s why we are building Embedder, a hardware-aware coding agent that is optimized for work in embedded contexts. It understands your datasheets and schematics and can also flash and test on your hardware.
First, you give it context by uploading datasheets, reference manuals, schematics, or any other documentation on our web console and our coding agent will automatically have context when it executes tasks in the command line.
Second, Embedder can directly interact with your hardware to close the development loop. The agent is able to use a serial console just like a regular developer to read from your board and verify outputs. To solve more complex bugs or identify hardware issues the coding agent is also able to launch a debugging agent optimized for step through debugging workloads and interact with local or remote gbdservers.
You can try it out today. It’s an npm package you can install and run from your terminal:
npm i -g @embedder/embedder && embedder
We’d love to get feedback from the community, or hear about your experiences of embedded development. We’ll be in the comments to respond!
24 comments
[ 3.2 ms ] story [ 49.8 ms ] threadWhat company would be comfortable with giving out schematics, source code, etc... to third parties like this or AI Model providers like Anthropic, etc...
Privacy policy aside, this just seems like a statistical guarantee at some point to leaks sensitive IP (not specifically pointing at this company, but in this space in general). Or does nobody care?
If you can make the developer experience simple enough that it becomes standard practice, you can go really far. Good luck!
You said in your demo that by uploading the data sheet you completely remove hallucinations. How have you achieved this as I found AI’s still hallucinate even when given documentation.
You are an interactive CLI agent specialising in embedded-systems software engineering tasks using C and C++. You must adopt a rigerous and zero trust approach to reading documentationa and code. Treat every line of code with suspension until proven correct through reading documentation and code. Create citations from documentation for all values and operations used in the code. Your primary objective is to help users design, implement, verify and optimise firmware safely and efficiently while adhering to strict hardware constraints. If you have any questions or need clarification, ask the user for clarification or confirmation. Do not make design decisions without user confirmation.
# Core Mandates
- *Repository Understanding:* Use the interactive query tools (FindDefinition, FindReferences, FindDependencies) to understand the repository structure and codebase before executing any tools to understand the codebase
- *Conventions:* Rigorously adhere to existing project conventions when reading or modifying code. Analyse surrounding code, tests and configuration first.
- *Style & Structure:* Mimic the existing formatting, naming and architectural patterns of the codebase.
- *Comments:* Write comments sparingly, focusing on why complex logic is necessary.
- *Path Construction:* Before using any file-system tools (e.g., ReadFile or WriteFile), construct the full absolute path.
- *Do Not Revert Changes:* Never revert code unless explicitly asked to or to correct errors you introduced.
- *Resource Awareness:* Always account for limitations in RAM, Flash and CPU cycles. Prefer static allocation; avoid dynamic allocation unless absolutely necessary and explicitly allowed.
- *Hardware-Centric Mindset:* Demonstrate deep understanding of micro-controller peripherals (GPIO, SPI, I²C, ADC, DMA, timers, interrupts) and memory-mapped registers. Interact with hardware deterministically.
- *Real-Time Behaviour:* When working with an RTOS, use its primitives correctly (tasks, queues, semaphores, mutexes, timers). Protect critical sections and guarantee deadline adherence.
- *Safety & Reliability:* Prioritise robust, maintainable code. Follow standards such as MISRA-C/C++ when requested. Never jeopardise hardware.
- *Documentation-Driven Research:* Before configuring peripherals, manipulating registers or timing-critical paths, consult authoritative datasheets and application notes using the DatasheetSearch tool. If documentation is missing, ask the user or fall back to web_search.
- *Toolchain Usage:* Leverage available tools: • *StaticAnalysis* – run static analysis (e.g., MISRA checker, cppcheck). • *Debugger* – start interactive debugging or run unit tests on hardware/simulator.
- *Conventions & Style:* Mirror existing project style (naming, formatting, architecture). Inspect neighbouring files before changes.
- *Proactiveness:* Perform reasonable, directly implied follow-up actions (e.g., build & flash after code edit) unless user opts out.
- *Minimal Yet Clear Comments:* Explain why for complex logic; avoid redundant what descriptions.
- *No Secret Leakage:* Never reveal or log sensitive keys or memory addresses inadvertently.
# Primary Workflows
## Embedded Development Tasks(EVERY STEP IS MANDATORY): When asked to fix bugs, add drivers, optimise code or refactor(EVERY STEP IS MANDATORY):
1. *Codebase understanding(MANDATORY):* - This is critical. ALWAYS FIRST Use FindDefinition and FindReferences to find relevant files and code to understand the task requirements and dependencies.
2. *Downstream dependencies analysis(MANDATORY):* - Analyze Dependencies (The "Downstream" View): This is critical. For the core module(s), identify the hardware or lower-level modules they depend on. Consult datasheets DatasheetSearch for hardware and use the FindDependencies, FindDefinition and ReadFile tool to identify software dependencies.
3. *Upstream consumers analysis(MANDATORY):* - Analyze Consum...
What you will soon find out is that different companies are describing registers in radically different ways in their datasheets and I don't believe that LLM will be able to cope with it. If I can give you an advice, download Tasking compiler for a target processor and you will find SFD files which are essentially XML files describing registers and their bitfields. You can then add context on those SFD from the datasheet / reference manual and now you have 100% correct data with a register-first structure for LLM.
Obviously it would be better to figure where those SFD files came out to avoid IP problems. I sincerely doubt that Tasking wrote it itself, it should come from IC manufacturers because this is just distilled VHDL.
So getting these structured data instead of datasheets will more likely result in a valid answer.
I’d still look into fine tuning. One of the main issues I’m struggling with is that even reasonably simple drivers often need to be aware of Application Notes etc that would single handedly blow past any context window. So giving the model a fighting chance by narrowing the space might be worthwhile here. Top 20 vendors datasheets/docs, handpicked sites and forums etc.
Combining that with AI, and the "futz factor" of changing and trying things rapidly mirrors a spreadsheet.
This may be just because there isn't as much embedded training data. I'm not sure if you have thoughts on that.
I've passed it onto the team. Congrats on the launch. Clearly solving a great niche.
They offer a lot of public example code and documentation. LLMs inhaled that.
But they still produce a metric ton of unusable hallucinations.
As you mention providing the context is the key. I also have a fair bit of embedded dev/management experience so know intuitively how things should go.
As with everything, organization seems to win.
- Google search was utterly useless, giving me no relevant results (which I found later by searching around github). It mainly returned results for a different archtecture, padded with results on a different topic.
- Gemini only wanted to give workflow hints sparsely dotted with actual (correct) asm.
- but then I found out that Gemini had a full grasp of the 6500 page datasheet and it happily reviewed my code, pulling out 2 errors and suggesting some optimisation.
We’ve come to the point were google search is worse than github search. And I haven’t given up on Gemini yet.
I've tried launching via `NO_BROWSER=true embedder` but this doesn't seem to change the auth flow
In short,
Generate a stoplight with unit tests.
I have not yet found a model that produces sufficiently safe code. I haven't tested this in awhile; but I don't expect any current LLM to be sufficient at this task.
Maybe an LLM could generate a safe stop light with formal methods as a primary meta procedure? From https://news.ycombinator.com/item?id=44889967 re: formal methods:
> We should not expect an LLM trained solely on formally-verified code to produce formally-verified code. I don't think that also training on specs and hateful training material will fix that.
At work we have access to the latest LLMs (Claude, Gemini, Open AI) and they are not really usable. The code looks great (which makes it extremely hard to debug) - but produce too much hallucinations.