Career guide · Embedded Systems × Generative AI

100 LLM-Based Project Ideas for Embedded Engineers

If you want to crack top embedded and automotive companies, start building LLM-based embedded projects. LLMs are no longer limited to chatbots. They can be combined with Embedded C, firmware, RTOS, CAN, AUTOSAR, MATLAB, debugging, BMS, Edge AI and real hardware.

1. Why this matters now

Embedded roles used to be judged on three things: can you write correct C, can you read a datasheet, and can you debug on hardware. Those skills still matter. What has changed is that engineering teams now use language models to speed up the repetitive parts of the job: reading logs, drafting drivers, writing test cases, summarising requirements and explaining crash dumps.

An engineer who understands both sides is rare. You know why a CAN frame is lost under load, and you also know how to give a model the right context so it can help find the cause. That combination is exactly what hiring managers at automotive suppliers, semiconductor companies and Tier-1 firms are starting to look for.

Projects are the fastest way to prove it. A GitHub repository that parses a real CAN log, asks a model for hypotheses, and checks them against a DBC file says more than a certificate. This guide gives you 100 starting points.

Three shifts driving demand

2. The common architecture

Nearly every project in this list follows the same pattern. Embedded data comes in (logs, traces, registers, code, specs). A pre-processing layer turns it into something compact. A model reasons over it with extra retrieved knowledge. A validator checks the answer against rules that are not negotiable, such as a compiler, a DBC file or a safety standard. Only then does the output reach the engineer.

What each block does

3. The 100 projects by group

The list is split into ten groups. Pick one group, build two or three projects inside it, and connect them. Depth in one area beats a shallow spread.

4. Group overview: skills, hardware and difficulty

5. How a project actually works: three worked examples

Example 1: AI CAN Bus Analyzer (65)

The goal is to take a raw CAN trace and tell the engineer what is wrong in plain language. The key design choice is that the model never reads the raw trace. A parser first decodes frames with a DBC file, computes statistics, and passes only the interesting parts onward.

Useful checks to compute before calling the model: cycle-time jitter per message, missing or duplicate counters, signals outside DBC limits, bus load percentage, error-frame bursts and bus-off events. The model then writes the story: which ECU likely misbehaved, when it began, and what to measure next.

Example 2: Datasheet-to-Driver Generator (26)

Here the model reads a sensor datasheet and produces an initial driver. The trick is to extract structure first: register map, bit fields, timing limits and the init sequence. Then generate code from that structured data rather than from the raw PDF text.

The loop is what makes it a real project. Generated code is compiled, run against a mock bus, and any failure is returned to the model with the exact error. Track how many iterations it takes; that metric goes in your README.

Example 3: LLM Quantization Assistant (91)

Given a model and a target device, the assistant proposes a quantisation plan, runs it, and compares accuracy and latency. The model chooses between options; the measurements decide.

6. Choosing the model: cloud or local

Automotive and industrial teams often cannot send source code or logs to an outside service. Learn both paths. A local quantised model on a workstation or a Jetson shows you can respect confidentiality. A hosted model gives stronger reasoning for hard problems.

7. Techniques that make these projects reliable

Structured context, not raw dumps

A 50 MB trace will not fit and would not help if it did. Reduce first: counts, outliers, time windows around the fault, symbol names resolved from the map file. Give the model a short, factual brief.

Retrieval from your own documents

Split datasheets, reference manuals and standards into small chunks with page numbers. Retrieve the few most relevant chunks for each question and require the model to cite them. If it cannot cite, it should say it does not know.

Tool use

Let the model call small, safe tools: decode a frame, look up a symbol, compute a CRC, run the compiler, read a register on a test board in read-only mode. The model decides which tool to call; your code executes it and returns facts.

Validators

A minimal prompt pattern

ROLE: embedded firmware engineer, Cortex-M4, FreeRTOS 10.
FACTS (do not invent beyond these):
 - Fault: HardFault, PC=0x0800_3A1C, LR=0xFFFF_FFF9
 - Symbol at PC: sensor_task+0x4C (sensor.c:112)
 - Stack high-water mark: sensor_task = 14 words
TASK: list the 3 most likely causes, ranked.
RULES: cite the fact used for each cause.
 If evidence is insufficient, say what to measure next.

8. Build roadmap

Do not start with project 100. Grow in stages so each project reuses what the last one taught you.

9. Risks and how to handle them

10. Making the project impressive

Recruiters skim. Help them in the first thirty seconds.

• Show a demo: a short recording of a real board or real trace, not only a screenshot.
• Show numbers: faults found out of faults injected, compile success rate, tokens per query, latency on the target device.
• Show failures: a section on where the assistant was wrong and what you changed. It signals engineering maturity.
• Show the validator: explain what stops bad output from reaching hardware.
• Explain the design choice: why this model, why this chunk size, why local or hosted.

README checklist

11. Interview angles these projects unlock