No!
There are reasons for saying no.
A few days ago, I wrote an article about Linux and microcontrollers.
Is there no future without Linux?
Microcontrollers are easier, with a lower threshold; it’s just that there are fewer technical knowledge points, especially since procedural programming is easier to master. Embedded Linux is multitasking, and with multitasking comes more complexity, allowing for the resolution of more complex business needs.
All business needs are forward-looking and market-driven, like the Chinese smartphone brands from ten years ago, the Symbian phones from a decade ago, and the Jetta cars seen everywhere. More recently, many oil-burning taxis in Shenzhen have now been replaced with electric vehicles.
As times change, business changes, and technology must change as well.
Those difficult-to-design GUIs, gaming experiences, screen sizes, and battery life all need to be eliminated and changed.
Additionally, the slow responses from original manufacturers’ technical support will gradually be phased out, driven by the market; previously, foreign chip companies had their own moats, but if these moats hinder our technological modernization, they will be replaced by domestic alternatives.
All of this requires embedded systems.
Talking about embedded systems sounds easy. Today, in my technical group, a senior said that Linux device drivers are easy, Linux kernel modules are easy, the Linux kernel itself is easy, and even the codec driver that took weeks to debug is also easy.
So, embedded systems are easy, there are many job opportunities, and there’s less coding to do.
This perfectly aligns with the two basic elements of many people’s desires: high pay and low work.
At this point, many might think, isn’t embedded systems just like that? Can’t I also switch to the embedded industry and earn a high salary?
But the reality is, if we take a camera driver as an example, to debug a camera driver, you first need to understand the SDK, right? You need to clarify the hardware schematic of the camera, right? You need to know how many voltage levels the camera requires, and you also need to know the location of the software code. The camera also has a motor driver; don’t you need to debug that too? The camera certainly involves initializing I2C, right? So, you need to understand the I2C driver and know how to debug it. The camera needs debugging for effects like white balance, exposure, gamma curve, etc.; you need to understand those too.
Then, at the application layer, you need to understand the V4L2 driver architecture and know how to call its interface to display images.
Well, none of this is too difficult. If you know these things, during an interview, you can casually brag about it, and the interviewer might think you have experience with cameras and let you handle it.
But what is the reality? The reality is, when you encounter a hardware device, and you want to display the module’s image, you have no idea where to start. You need to find the SDK and set up various environments. Your code might run normally, but there’s just no data coming out; what can you do?
Working with embedded software involves two critical parts: measurement and log analysis. Measurement can tell you if your hardware is functioning correctly, while log analysis can tell you if your software is executing correctly. However, many people take years to grasp these two skills.
After all, for software issues, the first instinct is to ask in the group, search online, and those with more experience know to look for specifications, contact the original manufacturer, or coordinate with FAE. Some more talkative ones will start meetings, looking for hardware, project managers, or procurement.
Eventually, they realize that solving even the toughest bug isn’t enough to get a raise, and they lose the motivation to challenge themselves.
As for whether Java developers face the same issues, I don’t know, but for those in embedded systems, these challenges are quite common.
In summary, the difficulty in embedded systems lies in the porting and debugging across various hardware platforms.