STM32 Smart Car Development: Where Does AI-Assisted Programming Hit Its Limits?

Background: AI Enters the Embedded Development Classroom

Recently, Shi Song, a biomedical engineering master's student at Tsinghua University, launched a course on Bilibili titled "STM32 HAL Library + AI Smart Car Crash Course." Built around the STM32F103C8T6 chip and the HAL library, the course's standout feature is using AI to help interpret every segment of code, with the goal of helping learners complete the entire project in three hours.

The STM32F103C8T6 is a 32-bit microcontroller from STMicroelectronics, based on the ARM Cortex-M3 core. Running at 72MHz with 64KB of Flash and 20KB of SRAM, it offers an excellent price-to-performance ratio and a rich set of peripherals — including timers, ADC, USART, SPI, and I2C — making it a popular choice for embedded education and small-to-medium projects. In the Chinese developer community, it's affectionately nicknamed the "Blue Pill." The HAL library (Hardware Abstraction Layer) is ST's official standardized driver library. Compared to the older Standard Peripheral Library, HAL abstracts away low-level register operations through higher-level APIs, and works alongside the STM32CubeMX graphical configuration tool, allowing developers to complete pin configuration, clock tree setup, and middleware integration through a visual interface — dramatically reducing project initialization time. This "configure-and-generate + library function calls" development model is precisely what makes a "three-hour completion" promise technically feasible.

The course didn't appear out of nowhere. Since the second half of last year, fans had been flooding the comments asking how to write obstacle-avoidance code, which sensors were used, and what techniques were involved. After nearly a year of preparation, the course officially launched in May of this year.

This course raises a question worth exploring in depth: In an era of increasingly capable AI-assisted programming, how much has the barrier to embedded development actually dropped? Can AI independently complete an STM32 smart car project?

The Real Difficulty of STM32 Smart Cars: Easy Once You Know It, Hard Until You Do

The Entry Barrier Is Lower Than You Think

On the question of difficulty, Shi Song offers a fairly candid assessment: for the average college student — or even a high schooler — this project isn't particularly hard. Many students complete a smart car build in their freshman year, simply because they have more free time. High schoolers don't attempt it not because they can't, but because they're busy preparing for college entrance exams.

In terms of prerequisites, learners only need a basic grasp of C — not even an advanced understanding. Knowing the fundamental syntax and common keywords is enough. If you're starting from zero, reading more code and asking AI questions will get you up to speed. The relevant academic disciplines are primarily electrical engineering and automation and control, which falls under the field formally known as embedded software development. Embedded software development is an interdisciplinary field spanning electronic engineering, computer science, and automatic control. Unlike software development on general-purpose computers, embedded development targets resource-constrained, purpose-built computing platforms — processors running at tens to hundreds of MHz, memory measured in kilobytes, and direct interaction with physical devices like sensors and actuators. In university curricula, it typically appears in upper-division courses for electrical engineering, automation, electronic information engineering, and computer science majors, drawing on prerequisite knowledge from microprocessor principles, digital circuits, C programming, and real-time operating systems (RTOS).

Meal Kits vs. Cooking from Scratch: Two Very Different Development Approaches

Commenters often say "even elementary schoolers can do this," questioning the value of such projects. Shi Song responds with a sharp analogy: it's the difference between a meal kit and a chef cooking from scratch.

When elementary school students build smart cars, they're essentially using the "meal kit" approach — the code is handed to them, they flash it to the board, and the car runs. Programming is mostly done through graphical tools. These educational platforms (like Arduino or micro:bit), paired with visual programming environments like Scratch or Blockly, dramatically lower the barrier by packaging complex low-level operations into drag-and-drop blocks — but in doing so, they hide critical mechanisms like interrupt handling, register configuration, and timing control. Genuine, technically substantive embedded development means writing code from scratch using the HAL library, debugging incrementally, and optimizing continuously. Professional development with the STM32 HAL library requires understanding concepts like GPIO operating modes, the relationship between PWM duty cycle and motor speed, timer interrupt priority configuration, and the trade-offs between ADC sampling precision and conversion time. The gap is similar to the difference between using Excel formulas for data analysis and writing machine learning algorithms in Python — one is tool usage, the other is engineering practice.

One technically savvy commenter in the thread put it well: Getting the car to stop smoothly, drive straight, control turning angles precisely, properly drive and protect the motors, match distance detection parameters to vehicle speed, and balance power consumption with performance — doing all of this well is genuinely impressive. These dimensions alone reveal the enormous amount of engineering detail hiding beneath what looks like a simple smart car project.

To be specific, each of these dimensions maps to a real engineering challenge: "stopping smoothly" involves tuning PID (Proportional-Integral-Derivative) control parameters, balancing response speed against overshoot; "driving straight" requires differential speed compensation between the left and right motors, since even motors of the same model have manufacturing tolerances that cause speed variation; "precise turning angle control" depends on closed-loop control with encoder feedback or precise PWM duty cycle adjustment; "motor drive and protection" involves selecting an H-bridge driver circuit (such as the L298N or TB6612FNG) and designing overcurrent protection; "matching distance detection to vehicle speed" requires dynamically adjusting braking distance based on the measurement cycle and effective range of an ultrasonic sensor (like the HC-SR04); and "balancing power consumption with performance" is especially critical on battery-powered mobile platforms, involving MCU low-power mode switching strategies and power management design.

This also addresses the "done in two hours" crowd. As Shi Song puts it: if the college entrance exam came with an answer key, you could copy it in an hour or two and score perfectly. But without the answers, nine years of compulsory education plus three years of high school might not be enough. It all depends on the angle from which you're looking at the problem.

The Real Capability Limits of AI in Embedded Development

What AI Can Do: Dramatically Lower the Learning Barrier

A defining feature of the course is using AI to assist with code interpretation — which reflects the most practical real-world application of AI in the embedded domain. AI has genuinely lowered the barrier to STM32 development in meaningful ways:

• Code interpretation: Paste a block of HAL library code into an AI, and it can clearly explain what each line does and the underlying logic
• Concept Q&A: When you encounter an unfamiliar embedded concept, AI can quickly provide an accessible explanation
• Code generation: Describe your requirements clearly, and AI can generate a basic functional code framework

What AI Can't Do: The Hardware Feedback Gap Is Unbridgeable

However, Shi Song is equally clear-eyed about the three fundamental limitations of AI in embedded development:

First, AI requires precise problem descriptions. For example, to light up an LED on an STM32 chip connected to pin PC13, you must tell the AI which pin it's on — and whether it's connected to the anode or cathode. These critical details — polarity, pin number — are things you need to already know. You can't ask meaningful questions without a baseline of hardware knowledge.

Second, AI lacks a global understanding of the engineering system. As a project grows in complexity, different functional modules begin to interact with and affect each other. Good embedded code must implement any given feature without disrupting other modules — which requires a developer with a system-wide perspective. Code generated by AI tends to focus narrowly on the immediate task, often overlooking its impact on other parts of the system.

Third, the absence of hardware feedback is the most fundamental bottleneck. This point is critical. Unlike pure software development, embedded development involves interaction with physical hardware. Even an AI Agent, after writing code to light up an LED, has no way to know whether the LED actually turned on — that feedback can only come from a human. This fundamentally limits AI's autonomous capability in the embedded domain.

In pure software development, AI Agents (such as Devin or OpenHands) can already execute an autonomous iteration loop: write code → run it → capture errors → fix the code. This works because software execution results can be fed back to the AI digitally — through terminal output, log files, unit test results, and so on. In embedded development, however, the final effect of the code manifests in the physical world: whether an LED lights up, whether a motor turns, whether a sensor reading is accurate. This information exists outside the digital domain. Even if register states can be read via JTAG/SWD debug interfaces, physical-layer verification — such as whether the motor's actual speed matches expectations, or whether the sensor's mounting angle creates blind spots — still requires human observation and judgment. This "Cyber-Physical Gap" is a shared challenge that AI currently faces across embedded systems, robotics, and IoT. Humans become an irreplaceable "sensor," responsible for feeding the results of the physical world back to the AI.

AI's Current Role in Embedded Development: Assist, Not Replace

Human-AI Collaboration Is the Best Practice

Shi Song's ultimate conclusion is refreshingly pragmatic: For now, AI's role in embedded software development is not to replace engineers, but to assist them.

This assessment aligns closely with what the broader industry has observed. The optimal human-AI collaboration model in embedded development looks like this:

1. Humans handle architecture design and system-level oversight — deciding which chip to use, which sensors to integrate, and how modules should interact
2. AI handles code generation and knowledge lookup — quickly generating HAL library functional code and explaining technical concepts
3. Humans handle hardware debugging and feedback validation — communicating physical-world results back to the AI to guide the next round of optimization

This human-AI collaboration model is precisely the core philosophy of the course: the code is already written; AI helps you understand it, and hands-on practice validates and internalizes it.

Looking Ahead: When Will the Loop Close?

As technology advances, AI may one day be able to directly receive hardware feedback through cameras, sensors, and other means — enabling full-pipeline automation of embedded development. The industry is currently exploring several possible technical paths: Hardware-in-the-Loop (HIL) simulation, which uses high-fidelity simulation environments to model physical hardware behavior so AI can debug in a virtual environment; Digital Twin technology, which creates real-time synchronized digital models of physical devices so AI can obtain hardware feedback indirectly by operating the twin; and machine vision and multimodal perception, which would allow AI Agents to observe hardware states through cameras (e.g., whether an LED is on, whether a car is moving) to close the feedback loop. Tools like Nvidia's Isaac Sim and MATLAB/Simulink's embedded code generation toolchain have already achieved simulation-in-the-loop in certain scenarios — but fully generalized, end-to-end automated embedded development remains a distant goal.

Until that day arrives, mastering the fundamentals of embedded development — understanding the interaction logic between hardware and software in platforms like STM32 — remains an indispensable core competency for every engineer.

AI has lowered the entry barrier to embedded development, but it hasn't lowered the ceiling for mastery. For anyone looking to learn smart car development, now is an ideal time to use AI to get up to speed quickly — while simultaneously building a solid hardware foundation.

Key Takeaways

• AI's role in embedded development is to assist, not replace — the absence of hardware feedback is the fundamental bottleneck for AI Agents in this domain
• Smart car projects have a relatively low entry barrier, but achieving smooth stopping, straight driving, and precise parameter matching requires deep engineering expertise
• Using AI effectively requires baseline knowledge to ask precise questions; AI's lack of system-wide awareness can easily cause inter-module conflicts
• The current best practice is a collaborative model: humans handle architecture design and hardware debugging, AI handles code generation and knowledge lookup
• AI has lowered the learning barrier for embedded development, but not the ceiling for mastery — foundational knowledge remains essential