Will Embedded Software and Hardware Engineers Be Replaced by Artificial Intelligence?

For embedded software engineers:

For newcomers to the field, writing an I2C driver can take an entire night. They have to meticulously read through the chip manual line by line to understand the register definitions. For instance, when configuring the I2C clock for the STM32, one must first calculate the APB1 prescaler and then set the FREQ bit in the CR2 register. A small oversight can lead to situations where the device is recognized but cannot read data.

However, now, if you open ChatGPT and input “Write an I2C driver for STM32F103 using the HAL library to read temperature and humidity data from address 0x48,” the code framework appears in less than three minutes, even including a rudimentary error handling structure. In the past, this would have taken at least half a day. Not only is writing code easier, but debugging has also become much simpler. Last year, while working on an industrial gateway project, the software would crash around 3 AM, and after three days of troubleshooting, I was still at a loss. Later, I used an AI code analysis tool, inputting the logs and code, and it directly highlighted the area where “dynamic memory allocation lacked boundary checks.” It turned out that during a sudden increase in data volume at midnight, memory fragmentation caused a heap overflow. If it were the old days, I might have had to stare at the oscilloscope and serial output, pulling several all-nighters. But if you say AI can replace software engineers, I would be the first to disagree. Last month, a client wanted to run a heart rate monitoring algorithm on the STM32L431, and an intern used AI to generate the ADC acquisition code, but the actual measured data fluctuated wildly. Upon reviewing the code, the issue was found in the sampling timing: AI had only written “enable ADC + DMA” according to general scenarios, without considering that the ADC on this chip requires a 2-cycle delay for the sampling clock to stabilize in low-power mode. This is a small note in the “cautions” section of the chip manual, which AI cannot comprehend the underlying hardware logic; it only generates code based on conventional patterns. Ultimately, by referring to the timing diagram in the datasheet and adding a few lines of delay configuration, the data stabilized. There are even more complex scenarios, such as industrial control with high real-time requirements. In a previous project for a servo motor controller, the position loop control cycle had to be within 1ms, with jitter not exceeding 50us. The FreeRTOS task configuration code generated by AI could run, but the task priority allocation was too “even,” causing interrupt responses to be blocked, resulting in actual cycle jitter of 200us. We later restructured the task architecture: setting the core task for motor control to the highest priority, using timer interrupts for hard real-time triggering, and optimizing the task stack size, which reduced the jitter to below 30us.

This kind of work, which involves finding a balance between performance, power consumption, and real-time capabilities, is something AI cannot currently handle; it lacks “system thinking” and only focuses on the correctness of individual code segments. To be frank, AI can indeed replace some “code movers.” For those who can only copy examples and modify pin definitions without understanding how register addresses are derived, they are likely to be eliminated in the future. However, the true value of a software engineer has never been about “writing code” but rather about “understanding principles, being able to design, and optimizing”: knowing why something is written that way, understanding the hardware logic behind the code, and knowing how to ensure software runs stably in specific scenarios. All of this relies on accumulated experience, which AI cannot learn.

For hardware engineers: The impact of AI on hardware is also significant. In the past, when designing PCBs, optimizing EMC (electromagnetic compatibility) required repeated adjustments: power lines had to be thick, high-frequency signal lines had to be short, and ground planes had to be laid around the crystal oscillator… A layout for a 6-layer board would require at least four or five revisions. Now, using AI routing tools, if you input the requirements for “USB3.0 + Ethernet + 485,” it can automatically route the lines according to impedance matching requirements, even planning the heat dissipation paths for you. Last year, when we designed an IoT gateway, the PCB layout time was compressed from two weeks to three days. Simulations are also much more accurate than before. Previously, when designing a power module, one could only estimate efficiency based on the formulas in the datasheet, and the actual results often differed by more than 10%. Now, using AI simulation tools, by inputting the parameters of inductors and capacitors, it can simulate efficiency curves under different loads and even predict performance degradation in high-temperature environments. But to say that AI can replace hardware engineers is even more far-fetched. In a project last year for a medical device, we needed to design a portable ECG monitor that required low power consumption, small size, and compliance with EMC Class B certification. The initial proposal from AI was “use XX chip + 4-layer board,” but it was immediately clear that there were issues: although the chip had low power consumption, its package was QFN32, which is inconvenient for a medical device that requires frequent debugging and maintenance; moreover, the cost of a 4-layer board was too high for the client to accept.

Ultimately, we adjusted the plan: switching to a chip with a QFP package and using a 2-layer board with a partial shielding design, which reduced costs while addressing maintenance and EMC issues. This kind of decision-making, which involves finding a balance between performance, cost, and manufacturability, is something AI cannot do; it lacks “business thinking” and only piles up solutions based on technical parameters. There is also the critical aspect of “understanding the physical world.” Last year, we developed an industrial sensor, and when the samples returned, we found that the temperature drift was severe, with an error exceeding 5% in the range of -20℃ to 60℃. AI simulations showed an error of only 1%; where was the problem? Upon disassembling the sample and examining it under a microscope, we found that the layout of the thermistor was too close to the power resistor. The power resistor generates heat during operation, causing interference with the thermistor’s temperature readings.

AI can only simulate based on “theoretical parameters,” but it does not understand the “implicit correlations” in the physical world, such as “power resistors generate heat” and “thermistors are sensitive to temperature.” Ultimately, we readjusted the layout, moving the thermistor away from the heat source, which resolved the issue. Previously, a startup company used AI to design a mainboard for a smart lock, and during mass production, 30% of the products failed to power on. Upon inspection, it was found that the input capacitor of the power chip was soldered incorrectly. The PCB layout generated by AI had reversed the polarity of the capacitor, and the engineer who drew the diagram did not carefully check the datasheet, directly following AI’s design. AI can make mistakes even with the most basic hardware knowledge, such as “package polarity”; without an engineer to “oversee” the process, the consequences could be dire.

Conclusion: The industry is always changing, from 51 microcontrollers to ARM, from bare-metal development to RTOS, and now to AI tools. But those who can truly remain are always the ones who can “solve problems.” AI can help you write code, design PCBs, and perform simulations, but it cannot address the core questions of “why do it this way,” “what risks does this entail,” and “how to optimize to meet actual needs.” Just like previous oscilloscopes and compilers, AI is merely a tool that enhances your efficiency. If used correctly, it can save you many sleepless nights and help you avoid many detours, but the prerequisite is that you must “know how to use it,” understand “how to guide it, how to check it, and how to compensate for its shortcomings.”

Leave a Comment