Suggest a budget embedded system setup to learn about rtos and get real world experience. I prefer Arm architecture

I see that Microchip keeps releasing new 8-bit PIC microcontrollers, but I can't think of why a device like this would be used in a new design when 32-bit ARM Cortex-M microcontrollers already exist at practically the same price. Is there any reason other than backward compatibility for companies to keep using these microcontrollers?

I’m exploring an idea for improving AI-assisted firmware reverse engineering, and I’d like to get feedback from people with experience in embedded systems, reverse engineering, and local AI tooling.
The problem
When reverse-engineering firmware for a proprietary 8-bit MCU, the datasheet may be available as a PDF, but general-purpose LLMs often don’t know anything about that specific chip.
This makes it difficult for an AI agent to reliably interpret memory-mapped registers, bit fields, peripheral initialization sequences, interrupt behavior, and hardware-specific code patterns.
Simply putting the PDF into a conventional RAG pipeline might help with document lookup, but I’m not sure it’s sufficient for accurate register-level analysis.
The idea
Build a completely offline, chip-specific knowledge base that an AI reverse-engineering agent can query through MCP.
The proposed architecture would include:
Structured register database: register addresses, bit fields, access permissions, reset values, and peripheral descriptions.
Document evidence: links back to the original datasheet, including page numbers and table references.
Knowledge graph: relationships between registers, peripherals, clocks, interrupts, pins, and hardware functions.
Semantic search: retrieval of relevant descriptions and hardware behavior from the documentation.
Reverse-engineering integration: MCP tools that let an agent query register definitions and relate them to instructions and memory accesses found in a firmware binary.
The initial implementation would target a single proprietary MCU, using Python and SQLite, with a lightweight graph representation. Everything, including document processing, indexing, and inference, should work offline.
I’m considering integrating it with tools such as REA, Claude Code, and IDA.
Questions I’d appreciate feedback on
Architecture: Would you use a structured database plus semantic search and a graph, or is this unnecessarily complicated for a single MCU?
Datasheet extraction: What tools or techniques work best for reliably extracting register tables and bit-field definitions from complex PDF manuals?
Register-level reasoning: How would you help an AI agent distinguish documented hardware facts from hypotheses inferred from disassembly?
MCP integration: Would exposing precise register lookups and relationship queries through MCP be a useful approach for firmware reverse engineering?
Prior art: Are there existing tools or projects that already solve most of this problem?
I’m particularly interested in practical experience and architectural pitfalls, rather than building a generic PDF chatbot.
I haven’t committed to the implementation yet, so I’m open to simpler or fundamentally different approaches.
Thanks for any suggestions!

Hi all,

I'm working on a project where I've created two platforms with CubeMX; Nucleo and Production. The project uses one or the other based on the build preset. CubeMX only takes care of some things for me using LL. I create the rest manually.

Pros:

- Covers both debug board and production in one project.

- I can re-generate MX files with no issues.

Cons:

- It adds doubled CMSIS files.

- Seems weird.

Is this a typical setup or is there a better way to do it? I'm not sure how to handle Git repository. Should I use "Copy only the necessary library files" and manually copy / paste the rest?

I will be grateful for any clues.

Hi everyone, The problem is that we waste a lot of time every day searching for keys, remote, wallet, charger etc. inside the house. I want to make a simple low-power Bluetooth tracker that can be attached to these items and ring when we search from the phone. I’m looking for practical ideas and suggestions from people who have worked on similar projects. Here are some specific questions I have:

Hardware: Which microcontroller is better for a battery-powered BLE tracker – nRF52840, ESP32, or something else? Any recommended modules? Power: How can I make the tracker last at least 6–12 months on a CR2032 coin cell? Any tips for deep sleep and advertising interval? Firmware: Any good open-source examples or libraries (Zephyr, Arduino, nRF Connect SDK) for making a simple beacon that can also ring a buzzer?

Mobile App: What is the easiest way for a beginner to make an Android/iOS app that can find the tracker and make it beep?

Challenges: What common problems should I expect (range inside house, battery drain, antenna design, etc.)? Any advice, circuit suggestions, or links to similar projects will be really helpful. Thanks in advance!

BLE #embedded #nRF52 #ESP32 #IoT #BluetoothTracker

I've been building a lighting engine for an electronic drum kit, and it's at the point where I can show off some of the progress. I'm not publishing it as open source right now because it is still at a very early stage.

What it is:

The engine is an MCU-friendly signal graph written in Rust that runs on an STM32F429 Discovery board, which also drives LED strips using a pretty efficient approach (the driver supports up to 16 strips; I run 8). The looks are built from nodes like noise fields, palettes, trails, blends, etc. The graph is very generic, so extending it with any new kind of kernel is extremely easy. All the math is fixed point for efficiency.

The input is built on a custom-made analog front-end board that shapes the envelope; some further DSP is also performed later in the firmware (I think I will eventually build a kick drum trigger module based on that). The ADC samples 8 inputs at 20 kHz.

The first part of the video is Studio:

It is a browser editor where a graph can be built and wired. The preview runs the same engine that the board does, through WASM, so the looks in the browser match the ones on hardware frame for frame. It also allows turning the knobs of any node or sending a replacement patch to the board in real time. There is also cost estimation for CPU and memory; the board will refuse a patch that is beyond its computational capacity.

The second part of the video is OBS (yeah, I know):

Since I was building a drum trigger engine, I needed a way to fine-tune and observe the detector, so basically OBS allows you to see in real time how hits are detected and, more importantly, adjust the knobs of the detector and see what it would detect with them.

Where it is going:

I want to eventually drive an 8-drum kit and light each drum with a separate LED strip. I'm also currently working on improving the clock system, allowing multi-clock signals using some clock calculus approaches. I've also been experimenting with audio, so this also works for any audio nodes; I've built several guitar effects that run on the development board (no audio input/output yet, so they're not playable for now).

I'll probably open-source it at some point once I have enough time to tidy everything up and stop being ashamed of the code (so, possibly never :( ).

I'm currently self learning embedded C with an STM32F103. And I wanna know your guys suggestion for a good unit test framework for embedded. I've tried Unity C before but any other that are more work oriented?

Hi all,

During my embedded carrier, I have never used microcontroller simulators or emulators to check the program binary, and I always tested directly on a prototype PCB. I am looking for a workflow which stays reliable. I have seen Renode being suggested, but the validity comes down to how each device is modeled in Renode. Do you ever use simulation to speed up work and reduce costs? any reliable methods?