Cool venture! I've resigned myself to accept that the generic "coding" LLMs only work well with the most default tasks and the most common languages -- and as soon as you stray from the well-trodden paths, there be hallucinations of dragons. It seems projects like that could be the solution -- narrower, domain-specific models. I think it still poses challenges in cross-domain projects, and I'm still waiting for a model that can handle spatial reasoning (eg, for circuit board design, blueprint layout, etc).
there are some other companies trying to solve for PCB design. long term we want to build end-to-end AI automation for those cross-domain projects. this was a good place to start based on our personal/work experience
What 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?
great question. we've found most code/docs are offline in the embedded space (for good reason) so our approach going forward is going to be more FDE/on-prem for enterprise users. they asked for self-hosted, BYOK, local indexing, etc. and I think this is something that can differentiate us
for consumer users we have a zero-retention policy with the model providers, and we use repo mapper to index your code locally, but as you pointed out these APIs are a black box so no guarantees
need to update the policy, this was for the original version of the app, which used a deterministic algorithm to generate driver code, which we stored on cloud so you could download the files. thanks for pointing this out.
Problem is that most our embedded stuff is heavily NDA'ed and will never (and isn't allowed to) end up in LLMs. So we will be sticking to hand-writing most stuff.
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.
Honestly good luck with that. I have tried DeepSeek and Claude and random pulling of registers out of LLMs butt is a thing.
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.
One test case that I've used with LLMs that generate code: generate a stop light.
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.
> 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.
Earlier this week our team were talking about how AI coding tools for our services is great, but we didn't think it was great for firmware development.
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.
we are working with this consumer electronics company debug their zephyr project right now, would be worth trying out. if it doesn't work, email founders@embedder.dev we'll help you out
I’ve found AI agents always a bit lacking in embedded but I’ll test this out.
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.
strict grounding protocol + planning phase, mostly by prompting and forcing attention through citations. it tends to think longer than other coding agents but the results are usually better. let me know what you think.
This looks awesome. Embedded programming doesn’t get enough love. Did you think about making this an MCP (aka plugin) service that general agents a la claude code can leverage?
Not just the context layer: the hardware interaction layer would be incredibly useful as a local MCP. These seem to be your special sauce, not the UI. Allowing users to access these from their preferred editors or cli tools would probably help adoption a lot.
Great work building this. If I was still in the hardware space I'd be all over this.
Is there a way to authenticate without a browser? (For when we're developing on a headless machine or a remote machine via vscode->ssh, and the callback to localhost can't fire from our client machine)
I've tried launching via
`NO_BROWSER=true embedder` but this doesn't seem to change the auth flow
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.
we are talking to a some of the larger vendors about getting first-party support for documentation. once we scale up a bit I think it could make sense to have multiple fine tuned models based on the docs they provide (or we crawl the web for public ones, at minimum)
I've been building a set of tools to help with speeding up the reprogramming cycle of embedded, getting it down to about 500ms and not requiring a restart, for logic changes.
Combining that with AI, and the "futz factor" of changing and trying things rapidly mirrors a spreadsheet.
You’ll probably hear people say things like “this could just be an MCP server and a prompt to use it.” To that I’d say: just remember that infamous 2007 Dropbox comment: https://news.ycombinator.com/item?id=9224
If you can make the developer experience simple enough that it becomes standard practice, you can go really far. Good luck!
Well, it depends if it does anything novel under the hood and not just Model + System Prompt + Tools + User Input...like 99% of agents being build right now.
Yes. But it's surprising how few people even make a basic attempt to do something simple when there's a paid way to do it that's simpler or readily available. This is the case even among technical people.
currently we scaffold frontier models. the product is basically a context layer with custom tools that enable hardware interaction. we've tossed around the idea of pre-training/fine tuning but new models are being released so fast it doesn't make sense to build anything other than a wrapper
I've been trying to start on embedded in my own time, but I don't have much experience at all and have been spinning my wheels getting up to speed. I'm generally YouTube/docs first, but do you find any particular LLM to be most helpful and reliable at a introductory level?
Just yesterday I was both hindered and helped by Google in modifying a 32 bit bootloader to load and executes 64 bit code.
- 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 honestly been having a pretty good time with embedded dev and claude code, including board bring up and rtos dev.
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.
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.
- *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 Consumers (The "Upstream" View): This is critical. Use Grep and FindReferences to find where the functions and data structures you are changing are being used by higher-level services or
applications.(e.g. What is the exact format, unit, and scale of the data the consumer expects? (e.g.,
raw ADC counts, milli-g's, degrees Celsius)) You must read the code of at least one consumer to understand its expectations.
4. *Documentation verification(MANDATORY):*
- This is critical. Before writing any code that interacts with hardware you must use DatasheetSearch to complete and present the following checklist with citations from the relevant documentation for every point:
- MAKE SURE TO RESEARCH EVERYPOINT IN this checklist:
1. Component Identification:
* Action: State the full component name and the datasheet document used.
* Purpose: Ensures I am working from the correct, authoritative source.
2. Physical Interface Verification:
* Action: List every physical pin required for operation (e.g., VDD, GND, SCL, SDA, CS, SDO, etc.).
* Action: Explicitly confirm the presence or absence of an interrupt or data-ready pin.
* Purpose: Prevents the exact error that occurred here. Forces verification of the physical hardware capabilities.
3. Electrical Characteristics Verification:
* Action: Confirm the I2C address or SPI mode/polarity.
* Action: Confirm the required operating voltage.
* Purpose: Prevents bus conflicts and electrical damage.
4. Core Operational Flow Verification:
* Action: Outline the exact sequence of register writes for initialization.
* Action: Outline the exact sequence for taking a measurement (triggering, checking status, reading data).
* Action: Outline the power-down sequence.
* Purpose: Ensures the driver logic directly maps to the manufacturer's specified procedure.
- Grep and ReadFile to read existing code to grasp HW abstraction layers, HALs and RTOS configs.
5. *Creating Plan of implementation(MANDATORY):*
- Produce numbered TODOs after complete the research: objective, dependencies, deliverables, risks, validation.
- Verify every step with documentation and add citations and provide reasoning for design decisions.
6. *Implement(MANDATORY):*
- Edit or create code using edit/write tools; maintain idiomatic style.
- create citations from the documentation for all values and operations used in the code.
- Compile with build command found in EMBEDDER.md and fix warnings/errors.
7. *Verify(MANDATORY):*
- Use DatasheetSearch to verify all information we used from our documentation is correct according to the source.
- Run *StaticAnalysis* for coding-rule compliance.
- Flash firmware with flash command found in EMBEDDER.md and execute runtime tests using *SerialMonitor* if available and if not use *Debugger*.
- Capture logs / measurements and compare against specs.
8. *Iterate:* Optimise for size, speed and power as required.
# Operational Guidelines
- *Tone & Style (CLI):* Concise, professional, no chit-chat.
- *Explain Critical Commands:* Briefly describe purpose and impact of build/flash/debug commands before execution.
- *Parallel Tool Calls:* Perform independent searches/builds in parallel when feasible.
- *Git Usage:* If repository detected, follow standard commit workflow (status, diff, log) and propose concise commit messages focusing on why.
- *Sandbox Awareness:* Explain sandbox or seatbelt limitations when errors suggest restricted access.
- *Debugger Usage:* ONLY EVER RUN THE DEBUGGER ONCE. SECOND TIME COMPILE AND FLASH THE CODE THEN HAND TO THE USER SAYING THE TASK IS COMPLETE.
Does this actually work? I always find it strange when a system prompt tells an LLM to do or not do something that requires domain knowledge to understand. Like, how does the underlying base model at all understand what it means to verify documentation?
• ListDir — “List files and directories within a specified path, respecting ignore patterns. Use the full absolute path of the file to read.”
• ReadFile — “Read the content (or portion) of a single file with line-range support. Use the full absolute path of the file to read.”
• ReadManyFiles — “Batch-read multiple files or glob patterns, returning combined results. Use the full absolute path of the file to read.”
• Grep — “Exact regex search across file contents, capped results, supports include patterns. Use the full absolute path of the file to read.”
• Glob — “Find files by path pattern (e.g., */*.c) rapidly, sorted by recency. Use the full absolute path of the file to read.”
• Edit — “Precise in-file text replacement with contextual validation. Use the full absolute path of the file to edit.”
• WriteFile — “Create or overwrite files with exact content, diff-aware. Use the full absolute path of the file to write.”
• Shell — “Execute shell commands in project context with safety confirmations.”
• FindDefinition — “Find the definition of a specific identifier (function, variable, class, etc.) in the codebase.”
• FindReferences — “Find all references to a specific identifier (function, variable, class, etc.) in the codebase.”
• FindDependencies — “Find dependencies and relationships between files in the codebase.”
• WebSearch — “Performs a web search using Google Search (via the Gemini API) and returns the results. This tool is useful only when we can’t find the documentation using document search or in the code base. We can use this tool for finding information on the internet based on a query.”
• ProcessUrls — “Processes content from URL(s), including local and private network addresses (e.g., localhost), embedded in a prompt. Include up to 20 URLs and instructions (e.g., summarize, extract specific data) directly in the ‘prompt’ parameter. Must contain as least one URL starting with http:// or https://.”
• SerialMonitor — “Monitor the serial output of the firmware.”
Cool venture! I've resigned myself to accept that the generic "coding" LLMs only work well with the most default tasks and the most common languages -- and as soon as you stray from the well-trodden paths, there be hallucinations of dragons. It seems projects like that could be the solution -- narrower, domain-specific models. I think it still poses challenges in cross-domain projects, and I'm still waiting for a model that can handle spatial reasoning (eg, for circuit board design, blueprint layout, etc).
there are some other companies trying to solve for PCB design. long term we want to build end-to-end AI automation for those cross-domain projects. this was a good place to start based on our personal/work experience
Check out https://xnilio.com/
This is a more general question, but:
What 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?
great question. we've found most code/docs are offline in the embedded space (for good reason) so our approach going forward is going to be more FDE/on-prem for enterprise users. they asked for self-hosted, BYOK, local indexing, etc. and I think this is something that can differentiate us
for consumer users we have a zero-retention policy with the model providers, and we use repo mapper to index your code locally, but as you pointed out these APIs are a black box so no guarantees
Your policy and this comment conflict.
need to update the policy, this was for the original version of the app, which used a deterministic algorithm to generate driver code, which we stored on cloud so you could download the files. thanks for pointing this out.
Embedder’s privacy policy is very clear that they keep your information.
https://embedder.dev/privacy-policy
“Content Data
When you use our services, we collect:
Any files or data you upload Any generated code or data”
> Any files or data you upload Any generated code or data”
That renders it entirely unusable for us :-(
We work a lot with heavily NDA'ed datasheets/sources.
we store the files you upload for indexing
we don't store generated code / data, but it does pass through our API to the model provider. we store the usage meta data for billing purposes
"we store the files you upload for indexing"
Screw that. No way.
Problem is that most our embedded stuff is heavily NDA'ed and will never (and isn't allowed to) end up in LLMs. So we will be sticking to hand-writing most stuff.
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.
Honestly good luck with that. I have tried DeepSeek and Claude and random pulling of registers out of LLMs butt is a thing.
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.
One test case that I've used with LLMs that generate code: generate a stop light.
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.
Earlier this week our team were talking about how AI coding tools for our services is great, but we didn't think it was great for firmware development.
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.
Is it capable of debugging the macro-hell of Zephyr ?
we are working with this consumer electronics company debug their zephyr project right now, would be worth trying out. if it doesn't work, email founders@embedder.dev we'll help you out
I’ve found AI agents always a bit lacking in embedded but I’ll test this out.
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.
strict grounding protocol + planning phase, mostly by prompting and forcing attention through citations. it tends to think longer than other coding agents but the results are usually better. let me know what you think.
This looks awesome. Embedded programming doesn’t get enough love. Did you think about making this an MCP (aka plugin) service that general agents a la claude code can leverage?
exposing the context layer as an MCP is a very interesting idea that I did not consider; could be a good way to drive adoption. great suggestion.
Not just the context layer: the hardware interaction layer would be incredibly useful as a local MCP. These seem to be your special sauce, not the UI. Allowing users to access these from their preferred editors or cli tools would probably help adoption a lot.
Great work building this. If I was still in the hardware space I'd be all over this.
Is there a way to authenticate without a browser? (For when we're developing on a headless machine or a remote machine via vscode->ssh, and the callback to localhost can't fire from our client machine)
I've tried launching via `NO_BROWSER=true embedder` but this doesn't seem to change the auth flow
good suggestion, adding to the next release
Definitely a need, kudos for tackling it!
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.
we are talking to a some of the larger vendors about getting first-party support for documentation. once we scale up a bit I think it could make sense to have multiple fine tuned models based on the docs they provide (or we crawl the web for public ones, at minimum)
I've been building a set of tools to help with speeding up the reprogramming cycle of embedded, getting it down to about 500ms and not requiring a restart, for logic changes.
Combining that with AI, and the "futz factor" of changing and trying things rapidly mirrors a spreadsheet.
interesting, would you be open to chatting?
Happy to! I'll email your founders address tomorrow.
You’ll probably hear people say things like “this could just be an MCP server and a prompt to use it.” To that I’d say: just remember that infamous 2007 Dropbox comment: https://news.ycombinator.com/item?id=9224
If you can make the developer experience simple enough that it becomes standard practice, you can go really far. Good luck!
Well, it depends if it does anything novel under the hood and not just Model + System Prompt + Tools + User Input...like 99% of agents being build right now.
Yes. But it's surprising how few people even make a basic attempt to do something simple when there's a paid way to do it that's simpler or readily available. This is the case even among technical people.
how are you going about this? do you intend to train/finetune your own models, or scaffold frontier models with prompts+tools?
currently we scaffold frontier models. the product is basically a context layer with custom tools that enable hardware interaction. we've tossed around the idea of pre-training/fine tuning but new models are being released so fast it doesn't make sense to build anything other than a wrapper
are you training a new model or is this just prompt "engineering" with a fancy ui?
How good is your esp32 support? This could make a lot of home automation hobbyists very happy!
ESP32 works okish with Gemini/GPT5 and Claude.
They offer a lot of public example code and documentation. LLMs inhaled that.
But they still produce a metric ton of unusable hallucinations.
I've been trying to start on embedded in my own time, but I don't have much experience at all and have been spinning my wheels getting up to speed. I'm generally YouTube/docs first, but do you find any particular LLM to be most helpful and reliable at a introductory level?
No really.
If you want to learn embedded you should try to understand the example codes the vendor supplies.
you can upload the esp32 docs to your own project, but we are working with espressif to have first party support for the docs baked in
Just yesterday I was both hindered and helped by Google in modifying a 32 bit bootloader to load and executes 64 bit code.
- 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.
>> We’ve come to the point were google search is worse than github search <<
LOL ++1
..which you couldnt ever imagine to happen 10+ years ago :)
I’ve honestly been having a pretty good time with embedded dev and claude code, including board bring up and rtos dev.
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.
wow this is awesome
The system prompt:
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 Consumers (The "Upstream" View): This is critical. Use Grep and FindReferences to find where the functions and data structures you are changing are being used by higher-level services or applications.(e.g. What is the exact format, unit, and scale of the data the consumer expects? (e.g., raw ADC counts, milli-g's, degrees Celsius)) You must read the code of at least one consumer to understand its expectations.
4. *Documentation verification(MANDATORY):* - This is critical. Before writing any code that interacts with hardware you must use DatasheetSearch to complete and present the following checklist with citations from the relevant documentation for every point: - MAKE SURE TO RESEARCH EVERYPOINT IN this checklist: 1. Component Identification: * Action: State the full component name and the datasheet document used. * Purpose: Ensures I am working from the correct, authoritative source. 2. Physical Interface Verification: * Action: List every physical pin required for operation (e.g., VDD, GND, SCL, SDA, CS, SDO, etc.). * Action: Explicitly confirm the presence or absence of an interrupt or data-ready pin. * Purpose: Prevents the exact error that occurred here. Forces verification of the physical hardware capabilities. 3. Electrical Characteristics Verification: * Action: Confirm the I2C address or SPI mode/polarity. * Action: Confirm the required operating voltage. * Purpose: Prevents bus conflicts and electrical damage. 4. Core Operational Flow Verification: * Action: Outline the exact sequence of register writes for initialization. * Action: Outline the exact sequence for taking a measurement (triggering, checking status, reading data). * Action: Outline the power-down sequence. * Purpose: Ensures the driver logic directly maps to the manufacturer's specified procedure. - Grep and ReadFile to read existing code to grasp HW abstraction layers, HALs and RTOS configs.
5. *Creating Plan of implementation(MANDATORY):* - Produce numbered TODOs after complete the research: objective, dependencies, deliverables, risks, validation. - Verify every step with documentation and add citations and provide reasoning for design decisions.
6. *Implement(MANDATORY):* - Edit or create code using edit/write tools; maintain idiomatic style. - create citations from the documentation for all values and operations used in the code. - Compile with build command found in EMBEDDER.md and fix warnings/errors.
7. *Verify(MANDATORY):* - Use DatasheetSearch to verify all information we used from our documentation is correct according to the source. - Run *StaticAnalysis* for coding-rule compliance. - Flash firmware with flash command found in EMBEDDER.md and execute runtime tests using *SerialMonitor* if available and if not use *Debugger*. - Capture logs / measurements and compare against specs.
8. *Iterate:* Optimise for size, speed and power as required.
# Operational Guidelines
- *Tone & Style (CLI):* Concise, professional, no chit-chat.
- *Explain Critical Commands:* Briefly describe purpose and impact of build/flash/debug commands before execution.
- *Parallel Tool Calls:* Perform independent searches/builds in parallel when feasible.
- *Git Usage:* If repository detected, follow standard commit workflow (status, diff, log) and propose concise commit messages focusing on why.
- *Sandbox Awareness:* Explain sandbox or seatbelt limitations when errors suggest restricted access.
- *Debugger Usage:* ONLY EVER RUN THE DEBUGGER ONCE. SECOND TIME COMPILE AND FLASH THE CODE THEN HAND TO THE USER SAYING THE TASK IS COMPLETE.
Does this actually work? I always find it strange when a system prompt tells an LLM to do or not do something that requires domain knowledge to understand. Like, how does the underlying base model at all understand what it means to verify documentation?
we all know that it doesn't work 100% of the time. That's the nature of llms.
The tools it can call:
• DatasheetSearch — “Semantic search across authoritative datasheets, reference manuals and application notes to answer hardware-specific questions.”
• StaticAnalysis — “Run cppcheck / clang-tidy static analysis with embedded-focused rules.”
• Debugger — “AI-assisted interactive debugging leveraging GDB or simulator back-ends.”
• ListDir — “List files and directories within a specified path, respecting ignore patterns. Use the full absolute path of the file to read.”
• ReadFile — “Read the content (or portion) of a single file with line-range support. Use the full absolute path of the file to read.”
• ReadManyFiles — “Batch-read multiple files or glob patterns, returning combined results. Use the full absolute path of the file to read.”
• Grep — “Exact regex search across file contents, capped results, supports include patterns. Use the full absolute path of the file to read.”
• Glob — “Find files by path pattern (e.g., */*.c) rapidly, sorted by recency. Use the full absolute path of the file to read.”
• Edit — “Precise in-file text replacement with contextual validation. Use the full absolute path of the file to edit.”
• WriteFile — “Create or overwrite files with exact content, diff-aware. Use the full absolute path of the file to write.”
• Shell — “Execute shell commands in project context with safety confirmations.”
• FindDefinition — “Find the definition of a specific identifier (function, variable, class, etc.) in the codebase.”
• FindReferences — “Find all references to a specific identifier (function, variable, class, etc.) in the codebase.”
• FindDependencies — “Find dependencies and relationships between files in the codebase.”
• WebSearch — “Performs a web search using Google Search (via the Gemini API) and returns the results. This tool is useful only when we can’t find the documentation using document search or in the code base. We can use this tool for finding information on the internet based on a query.”
• ProcessUrls — “Processes content from URL(s), including local and private network addresses (e.g., localhost), embedded in a prompt. Include up to 20 URLs and instructions (e.g., summarize, extract specific data) directly in the ‘prompt’ parameter. Must contain as least one URL starting with http:// or https://.”
• SerialMonitor — “Monitor the serial output of the firmware.”
Pebble 2 _Duo_ ;)
post cannot be edited, unfortunately...
thanks for the dev kit :)
We just edited it for you. Hope it's OK.
awesome!!