Word Count: 18000 Content Index: ⭐⭐⭐⭐⭐
The Concept of Embedded Systems: Focus on Understanding the Concept of “Embedded”
1. From a hardware perspective, integrating CPU-based peripheral devices into the CPU chip itself.
For example, early computers based on the X86 architecture only had arithmetic and accumulator functions.
All chips needed to create external bridges for expansion, such as serial ports, which were implemented using external 16C550/2 serial controller chips.
Currently, such serial controller chips have long been integrated into the CPU, and while PCs have graphics cards, most embedded processors come with LCD controllers, which are essentially equivalent to graphics cards.
High-end ARM-based Intel Xscale architecture IXP network processors integrate PCI controllers (which can support four PCI slave devices or configure themselves as CPI slave devices); they also integrate three NPE network processing engines, two of which correspond to two MAC addresses for gateway switching, while the other NPE network processing engine supports DSL, requiring only an additional PHY chip to enable DSL internet functionality.
The IXP series can reach a maximum frequency of 1.8G, supporting 2G memory, with 1G×10 or 10G×1 Ethernet ports or Fibre Channel optical channels.
The IXP series should be the highest processor based on the ARM architecture integrated by Intel into the Xscale core.
2. From a software perspective, it involves selecting applications to include in the customized operating system kernel, compiling, and downloading the kernel to ROM.
When customizing the operating system kernel, the selected application components complete the software “embedding.” For example, when customizing the WinCE kernel, there are corresponding selections such as Wordpad, PDF, MediaPlay, etc. If we select these, they will be available in the interface upon CE startup. In contrast, in previous PC Windows operating systems, most applications required reinstalling.
3. Burning the software kernel or application file system into the ROM of the embedded system hardware platform achieves a true “embedding.”
The above definition is one I provided about embedded systems 6 or 7 years ago, focusing on understanding. There are many definitions in books, but within this field, no one dares to claim their definition is entirely accurate, including those experts and scholars, because embedded systems are a comprehensive discipline under the computer domain.
Layering and Professional Classification of Embedded Systems
The definition of embedded systems is quite vague, especially with numerous application forms emerging in recent years, leaving newcomers with a sense of apprehension.
Embedded systems are divided into four layers:
1. Hardware Layer, is the foundation of the entire embedded system. If you are familiar with microcontrollers and interfaces and can program in C and assembly language, starting from the hardware layer of embedded systems is relatively easy. The hardware layer is also the basis for the driver layer.
An excellent driver engineer must be able to read hardware circuit diagrams and independently complete CPLD logic design while being quite familiar with the operating system kernel and its scheduling. However, the hardware platform is foundational; value addition relies on software.
The hardware layer is better suited for those majoring in electronics, communications, automation, mechatronics, and information engineering. Required foundational knowledge includes microcontroller principles and interface technology, microcomputer principles and interface technology, and C language.
2. Driver Layer, this part is relatively challenging.
Driver engineers must not only understand circuit diagrams but also be proficient in operating system kernels to ensure that their driver programs do not monopolize the operating system’s time slice during system calls, preventing other tasks from running. Without a good understanding of operating system kernel architecture and real-time scheduling, and lacking a good driver writing style, many people may achieve what is described in most books on driver addition, but may not even reach the level of a junior driver engineer.
Such drivers, when called by applications, behave like opening a program in Windows — either interrupting the previous program or waiting a while before the newly opened program runs.
To be a good driver engineer requires three to four years of experience; without researching the operating system kernel, success is not easy. However, salaries in the embedded system’s four layers are the highest.
The driver layer is especially suitable for those majoring in electronics, communications, automation, mechatronics, and information engineering, particularly those with a focus on computer architecture. In addition to the foundational disciplines required for the hardware layer, they must also be proficient in data structures and algorithms, operating system principles, and compilation principles.
3. Operating System Layer
Currently, the operating system layer can only be described as simple porting, and very few people write their own operating systems, or write incomplete operating systems. Most of this work is done by driver engineers.
The operating system is responsible for debugging system tasks, managing disks and files, and real-time performance is extremely important in embedded systems. It is said that the XP operating system took Microsoft 300 people two years to complete, totaling 600 person-years. It is estimated that the software institute of the Chinese Academy of Sciences took several hundred person-years to develop its own Nuwa Hopen operating system. Therefore, this part of the work is relatively insignificant.
4. Application Layer, relatively easier.
If you know how to program interface functions under Windows, the only difference in operating systems is the corresponding changes in compilation and development environments. This is also true for programming related to Java.
In embedded systems, algorithms are handled by specialized algorithm experts, and there is no need to categorize them under embedded systems. However, if it involves embedded databases, network programming based on embedded systems, and protocol application development based on certain application layers (such as SIP, H.323, Asterisk), it becomes more complex and challenging.
Changes in Embedded Field Divisions
Many so-called experienced individuals believe that embedded low-level software and hardware technologies do not change much; the more experience one has, the more valuable one becomes, and the older one gets, the more desirable they are. In fact, this is a subjective, mechanical, and narrow-minded empiricism, lacking a global perspective, only seeing some fundamental technologies in their own field, and not seeing the changes in the entire industry and related disciplines, a case of seeing only a small piece of the puzzle.
Using modern football and basketball as an analogy, the development history of modern football and basketball is much longer than that of embedded software, hardware, and other high-tech developments. Those who adhere to such mechanical, narrow-minded views certainly believe that playing basketball means learning how to dribble, break through, pass, shoot, while playing football means learning to pass, stop, dribble, tackle, shoot, and position, all of which have existed for 50 years or even 100 years, unchanged from now. What they fail to see is that tactics and positional divisions in basketball and football undergo major changes every 5-10 years.
For instance, in basketball, the evolution from a strong inside game dominated by muscular centers to a small-ball three-point shooter era has increased the requirements for inside players to shoot from mid-range and beyond, making larger inside players without shooting range less desirable.
In football, the changes in divisions and tactics are even more pronounced, from the ancient Brazilian star-studded 424 WM formation with individual technical flow to Italy’s chain defense, from the classic 442 formation, with one tall and one fast forward or two tall English-style long-ball tactics, to the first generation of 433 all-out attack and defense play style. From the traditional 4231 formation with classic wingers, a classic 10-position attacking midfielder, and a sweeping defensive midfielder to the prevalence of Spanish-style Tiki-Taka short-pass penetration football, and now high-pressing, the disappearance of classic attacking midfielders and defensive midfielders, with versatile B2B midfielders becoming popular. Other positions, such as inverted wingers cutting inside, false 9 formations, and full-backs increasingly required to assist in attacks rather than just defend against opposing wingers, have also changed. Central defenders are now expected to have better passing skills, not just defense and tackling. Past players who achieved many successes and honors but have single positions that do not meet modern high-pressing and flexible positional requirements are becoming less marketable.
Just like modern football and basketball, which have developed over 50 to 100 years, seemingly unchanged, they have actually gone through so many tactical and positional changes, with different eras requiring different positional players. How much more so in the past twenty to thirty years, with the rapid development of electronic information and embedded technology? Returning to the topic, let’s analyze the changes in the division of labor and skill requirements for hardware engineers and embedded software engineers.
1. Hardware Engineers
Initially, without integrated circuits and digital chips, designing a system required discrete components like transistors, resistors, capacitors, and inductors. At that time, hardware engineers needed a high level of proficiency in analog circuit design, being well-versed in application business logic as well as analog circuit design. One can look at the complexity of the analog circuit diagram of the classic uC741 amplifier in analog electronics books.
Later, small-scale analog and digital chips (such as the uC741 amplifier, 74LS04 digital gate circuit, NE555 clock generator) emerged, allowing hardware engineers to use these chips along with some peripheral circuits to build their systems, lowering the barriers to hardware design and enhancing product diversity, but they still needed to be proficient in application business logic.
As time went on, the advent of ASICs and large-scale integrated circuits, as well as embedded programming chips, integrated many algorithms and logic control functions into ASIC chips or implemented them using programming software in embedded processors. The requirements for hardware engineers regarding application business logic have significantly decreased, and the design of peripheral circuits has also diminished. For instance, in power supply design, one could buy TI’s switch-mode power supply chip and add only a few peripheral circuits to create a high-performance switch-mode power supply without needing to master various complex control algorithms and power factor compensation techniques. At this point, some hardware engineers began developing microcontroller programming skills, while others focused on EMC, PCIe, WiFi, USB, DDR, and other digital and analog interface standards certification, leading to a more specialized division of labor in hardware.
Currently, chip manufacturers provide not only standalone chips for hardware engineers to design circuits but also ready-made modules or turn-key solutions based on chips, allowing for plug-and-play without the need for PCB prototyping, enabling rapid validation of ideas and product schemes. Moreover, these modules and solutions provided by manufacturers are already certified for safety, automotive, and EMC standards, significantly lowering the barriers for hardware development and improving development efficiency. Many hardware engineers now modify, validate, and trim redundant components on manufacturer solution boards to save costs and may also be responsible for supply chain and production management-related tasks. The previously profound knowledge and experience in digital, analog mixed circuits, and discrete component circuit design are becoming less relevant (except in a few chip design scenarios).
2. Embedded Software Engineers
Over 20 years ago, most embedded engineers developed drivers and relatively simple control and communication systems using C language and assembly on 8-bit microcontrollers. At that time, microcontrollers did not have the advanced features they do now, and many peripherals or circuits needed to be built to enhance product functionality. Back then, embedded development required not only programming skills but also a relatively high understanding of hardware, as engineers had to design general hardware schematics and even draw two-layer PCBs. Only when encountering power supply, RF, or EMC hardware issues would they need to hire specialized hardware engineers.
Later, more complex 32-bit MCUs were developed, and as MCU capabilities grew, system requirements became more complex. Embedded engineers needed to develop multiple platform drivers and even upper-level application programs. At this point, companies generally hired specialized hardware engineers for PCB layout and some schematic design work. Embedded software engineers only needed to design the core functional I/O parts of hardware schematics, read chip manuals, and the hardware capability requirements for embedded engineers began to decrease, with most focus shifting to software development.
Subsequently, embedded development using DSP processors and RTOS real-time operating systems emerged, with hardware becoming increasingly integrated and complex. Embedded engineers’ understanding and requirements for hardware began to diminish, limited to reading schematics, configuring some I/O pins and registers, while schematic design was typically handled by specialized hardware engineers. However, embedded software engineers working with DSPs needed to be familiar with certain business algorithms, while those working with RTOS had to understand data structures, operating systems, and computer networks. Driver development also began to become framework-based and modular rather than limited to bare-metal development, configuring registers and simple business logic.
Currently, embedded systems predominantly use SoCs running complex operating systems like Linux/Android, with DSPs and other specialized CPU cores integrated into SoCs, accessed through drivers. Embedded engineers generally do not participate in hardware schematic design, and hardware capability is no longer a significant barrier. They only need to learn textbook knowledge from circuit, analog, and digital electronics, and be able to read others’ I/O part schematics. Reading data sheets and configuring registers is only occasionally required, as chip manufacturers and the Linux open-source community have integrated many product-level chip driver programs into the Linux kernel, configured registers, and lowered the barriers for using system-level software (a few embedded engineers work in high-barrier professional fields for driver development, such as audio and video, GPU, display, and security), allowing embedded engineers to focus more on specific applications and business logic development.
Through these changes in the division of labor in technical fields, the entry barriers and work focus for embedded engineers have shifted from hardware to schematic I/O design, to driver development, and to application business logic. Each part has its technical difficulties, and no technology is superior to another; we should focus on current priorities, adeptly identify the main contradictions among various issues, and learn and improve ourselves accordingly, being mindful of the mainstream technology trends and changes, and never be bound by past dogmas.
Current Challenges and Key Points of Embedded Technology
Currently, the key challenges in embedded technology are threefold:
1. Proficiency in C/C++ programming.
C language programming is not originally a major barrier, but because most domestic electronic information majors start with C language and the quality of selected domestic textbooks varies widely, and coding styles are inconsistent, this creates an artificial barrier for beginners. However, as long as one is willing to invest time and effort to study a few classic foreign C language textbooks recommended on Douban, and then learn data structures, object-oriented programming, and other foundational computer knowledge, practicing and writing code will not pose a significant problem.
As for C++, previously, embedded engineers working with microcontrollers and RTOS primarily wrote C programs and did not use C++. However, with embedded development based on Linux systems, the focus will shift to complex business logic application programming. In large-scale complex business logic and GUI programming, using pure C language has become increasingly inadequate, and the use of C++ for embedded application programs will become more common. However, C++ is inherently more complex, and one cannot expect to master over 95% of its features like C language. There will always be many language features that are either unused or unfamiliar, requiring finding suitable projects for practice, gradually reviewing books for consolidation, and progressing step by step. Mastery of C++ will require considerable time; currently, the general expectation is to grasp basic procedural and object-oriented programming methods, frequently use smart pointers, and being able to understand complex template programming is sufficient, without needing to master all intricate techniques.
2. Mastery of computer architecture and operating system-related issues.
This area of knowledge is considered a challenge in computer foundational theory. Although there is an abundance of related books and materials available, and commercial-grade Linux kernel source code can be downloaded online, digesting it requires patience. Many embedded engineers who work with microcontrollers and bare-metal and RTOS development are unable to enter the world of Linux development largely because the Linux operating system indeed presents certain challenges. For this area of knowledge, it is not required to master every line of the Linux kernel source code (which is impossible), nor to independently write a complex commercial operating system (which is also unrealistic), but one should understand the basic working principles and mechanisms of the operating system and computer architecture, and know what the operating system generally does and how it processes API calls.
This is a tough nut to crack, but it is manageable. With so much information and experimental resources available today, it should not pose a significant problem for those willing to invest time and patience.
3. Business application skills.
Why do we need to develop embedded computer systems? Because embedded computer systems can be tailored and customized according to the demands of different business scenarios. Ultimately, business is the true lifeblood of embedded systems, and the salary differences for embedded engineers in different business directions can be substantial (of course, in a few companies, developing operating systems also falls under their business). Embedded engineers with influence and status within a company possess business skills that are highly aligned with the company’s current profitable business direction, fully meeting the company’s business needs.
Currently, if embedded software engineers want to increase their income, they must follow the mainstream profitable business trends and enhance their related business application skills. Of course, many niche businesses will not offer opportunities unless one is in relevant companies, and high-level materials related to popular businesses are not easily obtainable through the internet and introductory training videos. Therefore, the current stage’s business entry barriers are the true barriers for embedded systems in various fields. One must learn to analyze and grasp the current mainstream cutting-edge business directions, study and improve oneself purposefully, and ensure that the knowledge acquired maximizes its “monetary” potential.
How to Adjust Learning and Career Development Directions
Embedded engineers can adjust their learning and career directions in the following three ways:
1. Do not overly fixate on hardware barriers and register configurations.
As Mao Zedong’s “On Contradiction” suggests, one must clarify which contradictions are primary and which are secondary, and when addressing issues, one should be adept at grasping the primary contradiction.
Similarly, in current embedded learning and development, hardware barriers and register configurations are no longer the primary contradiction; they are one of many secondary contradictions affecting problem-solving. The true primary contradiction is application business development and mastering the workflow of the operating system, allowing the operating system to effectively support and collaborate with application business to achieve system functionalities.
Therefore, while approaching hardware and register configuration, it is essential to analyze and solve related issues with an objective and rigorous attitude, but do not spend excessive time on hardware principles and data manual register learning, as this would be a high-investment, low-return endeavor. Embedded engineers should be able to roughly locate hardware-related issues and hand them over to professional hardware engineers for resolution. The requirement for hardware knowledge should only be to understand the basic analog and digital circuit knowledge found in textbooks, which is entirely different from the requirements for independently designing hardware circuits and passing various standard certifications.
2. Do not limit programming to the embedded side.
Currently, the boundary between complex business application programming in embedded systems and PC or server application programming is becoming increasingly blurred. Aside from occasionally needing to utilize specific hardware and driver characteristics of certain platforms to enhance and optimize program performance, much of the work involves stacking business logic code, simply compiling business code on different platforms using different compilers.
From a programming perspective, do not restrict programming solely to the embedded side; under the premise of being application business-oriented, actively attempt to develop applications on PC, server, or even web platforms, and also adapt and deploy new technologies used in PC and server programming to the embedded side, achieving a complementary effect while broadening one’s career path.
Currently, embedded systems have also introduced Python programming to build a complete automated testing system, and many test cases on the embedded side are also written in Python. Many embedded engineers working on STM32 and RTOS development are not limited to embedded programming, as their products often require integration with cloud servers through the Internet of Things, and they sometimes need to address application business logic on cloud servers as well as communication protocol development between cloud and embedded sides, moving away from the traditional notion of embedded development engineers.
Following this trend, the future skill requirements for embedded engineers will shift away from hardware skills, focusing on business-oriented application programming as the core, and possessing end-to-end vertical development capabilities from cloud servers to embedded terminals.
3. When considering job changes, be aware of business upgrade consciousness.
Finally, one should aim to change jobs purposefully, not only considering salary issues but also whether the next job will expose them to mainstream profitable business knowledge, whether there will be profitable business models in the future, and whether it will allow them to broaden their career paths. Pay attention to recruitment websites to see which companies and business types have the most recruitment demands, be daring to part ways with companies and businesses that engage in price wars or are not profitable, and timely jump out of pits. Do not waste time on repetitive basic work and unprofitable businesses.
Embedded Engineers Must Have a “Special Skill”
There is a question: Is street cleaning important? Undoubtedly, it is a crucial job for a city. Imagine if cities like Beijing, Shanghai, New York, and Tokyo went a month without anyone cleaning the streets; what consequences might arise? Consider how many diseases would spread and how many people might die. Regrettably, for such an important job, many countries do not offer good compensation; city cleaners often only receive minimum wage.
You can argue a thousand times about the “unfairness,” but it still does not solve the problem. You can strive to become a member of Congress and establish new laws to change this injustice, but in the end, you will find yourself fruitless.
“There is only so much money; will you do it or not? If not, many others will.” In simple terms: it is because the skills required for cleaning jobs are too easily replaceable.
The same goes for engineers, not only in IT but in any field. If we do not possess unique skills, that is, if we lack a “special skill,” how can we dream of receiving treatment different from others? For the same task, if I can hire a fresh graduate for a monthly salary of 3000 yuan, why would I spend 15,000 or 20,000 yuan to hire someone with seven or eight years of experience? Am I foolish? Am I out of money to burn?
Many friends, six or seven years after graduating from university, when asked in interviews what their technical specialties are, some respond confidently, while others hesitate for half a day before saying: “C Language” or “Java Language“!
These friends cannot articulate their advantages or do so inaccurately. Simply put, they have thought too little about this area in their daily lives, leading to insufficient self-guidance, drifting along with the tide for years.
To excel in technology, from the first day after graduating from university, or even before graduation, one must be clear about where their “special skill” should be established. Only in this way can one clarify the direction of their efforts and strive, ultimately seizing their fate and asserting their value.
Specifically regarding embedded development, let’s explore how to make this choice.
First, let’s take a macro view of how responsibilities in this field are generally divided.
Product Manager:What type of products the company will make and when it can earn money, the product manager must accurately identify, or else the entire company will be busy without purpose. The core value of a product manager lies in accurate product definition.
Project Manager: The QCT of the entire product. Once the product definition and business plan are determined, the key lies in the realization of the product. The project manager’s responsibility is to control, coordinate, and execute product development to ensure the product is launched on time (T), while meeting the company’s quality standards (Q) and cost requirements (C).
Technical Expert:When a product requires a specific function, the technical expert must provide a technical solution, guiding the implementation of that function, ensuring it meets the product’s QCT.
System Architect:Responsible for the overall architecture and implementation of the product system. Ensures the quality of the product and the efficiency of product development. Architects often must also consider the reusability of development results.
Software Engineer:Delivers functional code blocks, ensuring quality, timelines, and efficiency. Ensures that the code delivered effectively implements the required functions, with minimal bugs and ease of maintenance.
Interface Engineer:Coordinates interactions between the software department and other departments, as well as outsourcing units, ensuring the product development meets QCT.
Development Environment Engineer:Ensures the quality of development tools, debugging tools, and other development environments, thereby ensuring team efficiency.
Development Process Improvement Specialist:Monitors internal and external collaboration within the organization, ensuring the smooth implementation of development processes, leading improvements in the development process, and enhancing organizational development efficiency.
Test Engineer:Responsible for product validation. Ensures that the developed product meets the product definition and industry standards, guarantees product quality, and continuously improves testing efficiency and shortens testing cycles.
Quality Specialist:Responsible for product quality and process quality, addressing and summarizing quality issues after the product leaves the factory, and preventing similar issues from recurring through process improvements.
Department Manager:Allocates departmental resources to ensure that all products meet QCT; recruits and trains employees to ensure the department has sufficient capability to meet the company’s evolving needs.
A long list of textbook roles is outlined here. However, what kind of role do we want to become? What skills or “special skills” do we need to develop to become such roles? Have we studied this carefully? After careful study, have we planned for ourselves? After planning, have we executed flexibly?
If none of this has been done, how can we expect to receive salary increases, or how can we succeed in job-hopping?
In technology, there are essentially five career paths:
1. Become a technical expert, reaching the level of Li Zhengdao, Qian Weichang, or Linus Torvalds;
2. Technical management, aiming for roles like Ray Ozzie, becoming a high-level executive in a company;
3. Entrepreneurship; 4. Technical marketing: although no longer engaged in technology, knowing how to promote technology;5. Changing careers.
Before reaching these positions, we must experience the various roles listed above.
This article aims to explore the technologies and skills required for an embedded practitioner and how to establish a “special skill” from various perspectives.
Let’s set aside personal qualities and business acumen for now, and discuss them later.
As a technical personnel, how should one choose the path for the growth of their “technical specialty”? This can easily lead to confusion, and this is a fact. Developed countries have treated this as a national project, each researching a set of skill systems and guiding engineers’ self-growth through qualification recognition. As far as I know, governments in countries like the UK, the US, and Japan have established such systems. Here, I would like to introduce the existing classification systems of these countries in conjunction with my own experiences.
First, we can categorize technology into three major categories:
1. Development Technology
2. Domain Technology
3. Management Technology
Here is a brief outline of the divisions of these three major categories.
Development technology refers to the skills necessary to complete a large-scale software development project, such as system requirement analysis, system design, software requirement analysis, software pattern design, detailed software design, code writing and testing, code integration (Integration), software validation, system integration, and system verification, including the tools, patterns, processes, and knowledge required at each stage.
Management technology refers to the skills necessary for project management and process management, such as division management, time management, cost management, quality management, communication management, procurement management, risk management, and personnel and organizational management, all of which belong to project management technology; while change management, configuration management, development environment management, development process selection, and intellectual property management fall under process management.
Domain technology refers to platform technology, interface technology, communication technology, multimedia technology, storage technology, sensing and control technology, information processing technology, application technology, etc.
The insight we gain from this classification is that whether we aim to become experts or executives, mastering development and management technologies is largely essential. The “irreplaceability” of an individual must be found within the domain technology. If one can become a top player in a specific domain technology within a company, they become irreplaceable because it would cost more to replace them. If one can achieve a top position in the industry in a certain technology, they possess the basic conditions to become the next “Ray Ozzie.”
Becoming irreplaceable and achieving a top position in a company is a rarity. If we settle for second best, we can become a “talented individual”. We can become “talented individuals” in various roles listed above. What aspects must we excel in to become such “talented individuals”? Perhaps this can be discussed later. For now, let’s break down the domain technology:
1. Platform Technology includes
1. Specific processors, such as comprehensive mastery of ARM processors, TI DSPs, or Nvidia GPUs.
2. Specific Operating Systems, such as mastery of Nucleus, Rex OS, Linux, etc.
3. Specific software frameworks, such as Java VM, and specific application frameworks like GNOME and KDE.
2. Interface Technology
1. Input processing: processing input generated by human actions, such as buttons, touch screens, smells, sound waves, G-Sensors, GPS signals, etc.
2. Output processing: display, sound, vibration, smell, light. Since GUI often involves input and output, we categorize GUI technology under interface technology, as it involves designing and implementing a complete set of operation and feedback processes to make it easy for users to learn and remember. In this sense, GUI should be considered platform technology, as it is a platform for implementing user operation processes.
3. Communication Technology
1. Design, implementation, and maintenance of certain layers of the ISO 1~7 communication model. Wireless communication involves changes from the physical layer to the network layer and is typically divided into wired and wireless communication technologies. Protocol stacks such as GSM, TCP/IP, and TD-SCDMA fall under communication technology.
2. Wireless broadcasting technology: DVB-T/H, T-DMB, CMMB, etc., are all part of wireless broadcasting technology.
3. Internet technology: This refers to communication protocols above the TCP layer, such as HTTP, IMAP, POP3, SMTP, FTP, etc.
4. Multimedia Technology
1. Sound compression and decompression technology: MP3, AAC, AMR, etc.
2. Image compression and decompression technology: PNG, GIF, JPEG, etc.
3. Video compression and decompression technology: H.263, H.264, MPEG4, etc.
5. Storage Technology
1. File systems: FAT32, EXT3, JFFS, etc.
2. Media technology: mastery of the physical media characteristics of memory, flash, disk, etc.
3. Storage interface technology: interface technology for hot-swappable and cold-swappable devices.
6. Sensing and Control Technology
1. Input technology for physical and chemical quantities: measurement technology for potential, current, vibration, light, pressure, and other physical and chemical quantities.
2. Output and control technology for physical and chemical quantities: output technology for electromagnetic, light, heat, speed, vibration, coordinates, and other physical and chemical quantities.
7. Information Processing Technology
1. Information input technology: data input, sound input, and other information input technologies.
2. Information security technology: encryption and decryption technology.
3. Data processing technology: data compression and decompression technology, embedded database technology.
4. Information output technology: Postscript language, XML language, SVG, and other general information format output technologies.
8. Application Technology refers to the implementation of specific purpose application software, often a comprehensive application of the above seven types of technology, such as:
1. Browsers
2. Messaging applications: e-mail, IMPS, MMS, SMS, etc.
3. VoIP applications
4. Video calls
5. Media players
Each of the eight areas listed is sufficient for a lifetime of work. I hope this extensive outline provides guidance for friends aspiring to enter embedded software development, those who have just graduated and stepped into society, those who have worked for many years in software without knowing how to develop, or those who mistakenly believe embedded systems are simple.
In the first five years after graduating from university, we typically “work in a field we love.”
After five years of university graduation, I hope to achieve “love the field and work in it!”
Progression in Embedded Linux
1. Master the Basics
The embedded systems profession is a comprehensive discipline that integrates computer hardware technology, computer software technology, and electronic circuit technology, encompassing a wide range of knowledge, including: digital circuits, analog circuits, principles of computer composition, basic microcontroller knowledge, basic C language, operating systems, data structures, compilation principles, computer control, computer networks, and more.
Before truly learning embedded development, it is essential to build a solid foundation. Among these, the most important subjects are basic C language, digital circuits, and principles of computer composition. For C language, one should be able to independently write and debug a program of 300 to 500 lines, understand the basic syntax rules of C language, and be able to flexibly use various pointers.
In terms of computer composition principles, one should understand the major components that make up a computer system, the structure of computer systems, understand system buses, and comprehend the relationship between processors and external devices, as well as how processors and peripherals coordinate to complete specific functions, and how software controls hardware through registers.
For digital and analog circuits, one should understand their basic principles and concepts, and be able to read simple analog and digital circuit schematics. Understanding registers and timing concepts in digital circuits and being able to read chip manuals and timing diagrams is essential. For other foundational courses, the key is to grasp some basic concepts and how to use them.
For students majoring in electronics, automation, communications, and computer science, most of the above courses are typically covered in the foundational or specialized courses offered in the second and third years. Due to a lack of practical experience, the learning may not be very in-depth, but some basic concepts and knowledge should still be understood. For any weak areas, one should strengthen their learning independently, which will provide a basic foundation for learning embedded development.
During the basic learning phase of embedded systems, the most critical aspects are basic C language and microcontroller fundamentals. It is best to be able to develop a small microcontroller program in C, such as implementing serial communication between a microcontroller and a PC, controlling LED displays with C, and controlling seven-segment displays with C. The learning tool needed during this period is a microcontroller 51 learning development board. The Feiling OK-51 learning development board is recommended. For details:
2. Embedded Linux Application Development
After completing the foundational knowledge of embedded development, you should have a certain level of embedded development foundation and can begin designing embedded systems based on microcontrollers.
Microcontroller programming is also considered embedded programming, but here we regard microcontroller development as the basis for embedded system development, not as true embedded system development. Here, our embedded system development refers to application and driver development on embedded platforms equipped with operating systems, particularly on embedded Linux platforms.
While microcontroller development was once very popular, it is still widely used in some simpler systems. As hardware costs continue to decrease, more complex embedded devices are generally adopting embedded Linux operating systems for development, which greatly enhances embedded development efficiency, improves system stability and reliability, and reduces development costs.
Since Linux is an open-source operating system, you can understand the kernel’s implementation mechanisms by reading the Linux kernel. If necessary, you can even modify the kernel source code to improve system performance. Moreover, the global community participating in Linux development is vast, and there is a wealth of embedded Linux development materials and source code available online. Most functionalities you need to implement can be found in relevant source code online, allowing you to reference others’ code, which significantly enhances your work efficiency and technical ability.
In recent years, with the increasing number of participants in Linux development, the stability and real-time performance of Linux systems have improved significantly. Linux systems are now widely used on both servers and embedded device platforms. Major communication giants like Huawei, ZTE, and Lucent have begun migrating their devices’ underlying platforms from VxWorks to Linux, making embedded Linux a direction for embedded technology development and a banner for embedded technology.
For the above reasons, my suggestion is to learn embedded development by focusing on embedded Linux development. Compared to other embedded platforms like WinCE, you can truly learn more and grasp the essence of embedded technology, while aligning with the direction of embedded industry development, making it less likely to be eliminated by rapidly changing technologies.
With a foundational knowledge of embedded development and an understanding of why we should learn embedded Linux development, we can now begin hands-on learning. How do we start learning embedded Linux development, and where should we begin?
Learning embedded Linux development is not just about reading books; it requires practice and debugging. Embedded development differs from typical application development based on PCs or servers, as embedded application programs must be burned onto embedded boards or development boards to run. Therefore, the first step is to purchase a development board for yourself.
Once you have the development board, you can start learning about setting up the embedded Linux development environment, the embedded Linux development model, kernel porting and file systems, embedded Linux application porting, multi-process and multi-thread application design, and embedded Linux network programming. If you are interested in embedded databases or graphical software development, you can further learn about embedded Linux database development or graphical application software design based on QT.
For each chapter learned, you must validate what you have learned from the books through relevant experiments, while also enhancing your ability to write code and debug programs. Depending on the different foundations of the learners, this process may take 1 to 2 months.
After completing these courses, you will have the ability to design applications on existing embedded Linux platforms, making you capable of upper-level application development work in some embedded software companies. However, at this point, you may not yet be capable of developing embedded Linux systems and drivers, meaning you can only develop applications on an already constructed embedded Linux platform.
To be capable of reconstructing an embedded Linux software and hardware platform according to actual needs, you will need to proceed to the next stage of learning, which is embedded Linux system and driver development.
3. Embedded Linux System and Driver Development
With a foundation in developing applications on embedded Linux platforms, you should have a certain understanding of Linux’s functionality, the interfaces and system calls it provides for application development, and how to utilize device drivers for application design. With this knowledge, you can delve deeper into learning Linux system principles and driver development based on Linux, kernel trimming, file system construction, bootloader, and other foundational knowledge.
To learn embedded Linux system and driver development in depth, there is a lot of content to cover, including knowledge of computer software, hardware, and operating systems. At this point, you can refer to the following learning ideas. Since embedded Linux system and driver development is closely related to underlying hardware, we should start by learning about embedded hardware, including: ARM architecture, S3C2440 microprocessor interface design, clock systems, LCD screen interfaces, storage controllers, and system memory allocation, NAND FLASH interfaces, and NOR FLASH interfaces.
Once you have a certain understanding of embedded system hardware, you can then learn about bootloaders, understanding their concepts, functions, and principles, focusing on mastering the use and porting of U-BOOT. Next, you can learn about the embedded Linux kernel mechanisms, analyzing the composition of embedded Linux source code, kernel module mechanisms, kernel process management, memory management mechanisms, Linux interrupt systems, and kernel porting, among other topics. With a foundational understanding of the kernel, you can then learn embedded Linux device driver development, focusing on character device driver development, LCD screen device driver development, touch screen device driver development, USB device driver development, and network card device driver development.
After mastering these knowledge points and validating them through relevant experiments, you will have a good grasp of embedded Linux system and driver development, enabling you to handle most driver development work based on Linux platforms. Depending on the learners’ different situations, this stage generally requires three months to half a year. Through this stage of learning, you will have a certain foundation in embedded Linux development, no longer being referred to as a novice, and will have entered the ranks of embedded Linux development experts.
4. Reaching the Next Level
Having gained a deep understanding of embedded kernel and driver development, writing any driver will no longer pose a problem for you, and basic issues during the development process will not stump you. This is when you might want to optimize system performance, such as improving real-time performance, enhancing system startup speed, or optimizing memory management mechanisms. To achieve the level of modifying core kernel mechanisms, you will need to delve into the Linux kernel source code, referencing books like “Deep Analysis of Linux Source Code” and “Linux Situational Analysis,” to gain a deeper understanding of the implementation mechanisms and principles of various parts of Linux, as well as potential problems.
You can only propose better improvement plans after thoroughly understanding existing code and implementation mechanisms. If you can reach this level, you will be among the best of the best, able to stand out among peers.
5. Misconceptions
1. Fully immersing in learning desktop or server versions of Linux systems.
The Linux desktop environment is merely a development tool for embedded Linux, a development environment. Our goal is not to learn how to configure and use Linux servers; advanced configurations and uses of Linux servers belong to another field outside the scope of embedded Linux discussions.
When engaging in embedded Linux development, we treat the Linux desktop environment as a tool to run embedded Linux development tools, such as the GCC compiler and make tools, to develop our embedded Linux applications. For embedded development engineers, it is unnecessary to spend excessive time and effort studying Linux desktop and server applications; a basic understanding of essential operations is sufficient. Today’s desktop Linux systems have user-friendly graphical interfaces, making them as easy to use as Windows. For example, many operations in Ubuntu can be completed through the graphical interface, eliminating the need to memorize every Linux command. Familiarizing oneself with the Linux desktop system and basic operational commands can be achieved in just 1-2 days.
2. Directly reading Linux kernel source code.
Many aspiring Linux learners attempt to read the Linux kernel source code without any understanding of what Linux is or how to use it, spending a lot of time reading books like “Deep Analysis of Linux Source Code” and “Linux Situational Analysis.” This often leads to confusion and frustration, ultimately resulting in abandonment.
This is also a common misconception among students learning embedded Linux. After gaining a certain foundational knowledge of embedded Linux development, approaching the Linux source code with specific goals can greatly enhance your technical abilities. However, attempting to read the Linux kernel source code without any background knowledge or understanding is akin to hitting a wall, leading to frustration.
3. Beginners should act within their capabilities.
Do not assume that since driver layer salaries are high, you should make it your direction without considering your own characteristics. In the realm of embedded systems, there are experts at every layer, and naturally, those experts correspond to high salaries. I work in the hardware layer, and previously, my personal income tax deductions amounted to nearly 3000 yuan per month. Of course, I simultaneously fulfilled the roles of both an engineer and a supervisor. There are few people who can compete with me in the hardware field, which is why I receive such a high salary.
4. Choosing a development system.
Many ARM beginners hope to have a system they can use, but they often develop a misunderstanding that a higher processor version or performance is better. For many beginners, this misconception should be approached rationally. The choice of a development system ultimately depends on which direction you wish to pursue in embedded systems: whether in driver development, application development, or hardware layer design and board-level testing.
If you aim to advance from the operating system layer or application layer, higher processor performance is certainly advantageous. However, learning this independently is a significant challenge that cannot be resolved in just a few months, a year, or even two years.
Predictions for the Embedded Industry
From the perspective of upstream semiconductor companies, I would like to share predictions for the embedded industry:
(1) The Major Direction of Embedded Development – SoC Will Be Mainstream
Current mainstream can be divided into two categories: bare-metal series and system series. The first type, bare-metal series, is easily understood, such as C51, MSP430, and PIC microcontrollers. The development processes and methods are fundamentally the same; using BSP packages provided by semiconductor manufacturers and configuring registers according to manuals can meet simple functional requirements. The system series essentially involves non-real-time operating systems like Linux and Android and some real-time operating systems. As operating systems introduce multi-tasking and comprehensive management mechanisms, discussions shift towards chip architectures and instructions, such as PowerPC, ARM, MIPS, etc. These processor chips are often used to address complex requirements, with customization left to embedded application engineers or CS engineers familiar with the business and technology, enabling a seamless integration with computer developers to create diverse functional devices. In this view, operating systems can be seen as a bridge connecting the embedded and computer industries.
Traditional embedded systems have generally followed this pattern. What predictions can we make?
C51, MSP430, and PIC will inevitably be phased out. This is not due to their lack of capability, but rather due to the characteristics of the semiconductor industry. The production cost of semiconductor devices is distributed according to the number of molds produced; the more produced, the greater the demand, the lower the cost. In the future, scenarios requiring real-time performance based on MSP430 and C51 may opt for ARM processors centered around Cortex-M (the licensing fees from ARM are incredibly low, truly a conscience of the industry). As production scales increase, costs decrease, and future expansions become easier. Moreover, ARM has continuously invested in cost optimization for the Cortex-M core.
From the development of bare-metal systems, we can observe a developmental trend toward the SoC model. Core architectures are handled by specialized companies, while companies focus on their strengths; all functional components are integrated into a single chip. For instance, during a training session I attended this year regarding chip IP by ARM, I learned a lot from the introductions of new entrepreneurial semiconductor companies, opening up a new world for me. In an IoT case study, one company focused on NB wireless transmission, using an ARM-based core processor, specifically thanking ARM for not charging fees for demo evaluations of their chips until production, significantly reducing the risks for start-ups.
This company chose a solution based on the mature Cortex-A series processor from ARM, focusing on NB wireless baseband and modulation algorithms for the MAC layer, ultimately integrating them into a single chip for production and testing. This is an IoT chip case utilizing the SoC model. The SoC model encapsulates an entire system into a single chip, similar to how complex analog and digital amplification circuits were previously integrated into chips. In the application of IoT, embedded SoCs will inevitably become a trend. The relationship between embedded systems and IoT is clear; embedded systems, combined with CS and the Internet, create a large-scale network known as IoT. Embedded systems play a foundational role in IoT deployment, requiring small size, long lifespan, and low power consumption, making SoC the preferred choice.
Regarding the SoC model, many believe that most of the workload lies in semiconductors, and embedded software development seems less relevant. However, this is not the case; rather, the requirements for embedded software development are rising. For example, multi-core and multi-layer SoCs have existed since the early 2000s, such as TI’s OMAPL138, which combines DSP (C6748) and ARM (ARM9) architectures. Embedded software faces significant challenges, such as inter-core communication, determining how DSP communicates with ARM. This is also true for the well-known ZYNQ, which combines FPGA and ARM in a multi-core heterogeneous platform. Resolving inter-core communication remains a challenge. Moreover, Nvidia’s TX2 employs an SoC model featuring the ARM Cortex-A5x series alongside its GPU. Many developers use a model from the Linux kernel for IPC, commonly utilized in bare metal. When using an operating system, Linux addresses multi-core heterogeneous communication through TI’s syslink driver-level components, while ZYNQ employs RAM memory reading methods to package interfaces. These developments in multi-core communication applications are complex, let alone developing BSP support for them.
In the future, embedded systems will not only rely on traditional CPU + peripheral modules to read external data via peripheral buses, but will integrate into the chip itself, becoming a single system.
The focus of development will not solely rest on traditional embedded knowledge but will also encompass semiconductor SoC knowledge. The demand for driver development will increase, and embedded systems will become increasingly integrated, moving away from surrounding hardware, and deeply integrated, developing from the outside in, with SoC becoming mainstream.
(2) The Importance of the Linux Kernel and the Crisis for Embedded Application Engineers
In response to the aforementioned trend of SoC development, a purely embedded software engineer will no longer meet the demand. With technological iterations, the definitions of these roles have also been redefined, and traditional skills can no longer keep pace with the trends. As industry professionals, we must adapt to these changes. Embedded systems require constant learning and reflection; personal technical trees must continue to branch out. The increasingly integrated development platforms will quickly become outdated, necessitating that the skills we develop be more diverse. Therefore, we cannot be confined to a specific company or product.
The Linux kernel is a hefty book, and the author of the preface on the first page tells us that this is not the entirety of it; writing the entire kernel as a book is impossible, only the most core aspects can be introduced. The Linux kernel can be described as the best code written by the best engineers in the world, providing excellent learning materials. Our goal in studying the kernel is not to learn how to write the kernel, but to grasp its models and mechanisms, such as paging, kernel scheduling, memory management, deadlocks, etc. These mechanisms can be integrated into any solution we create, such as the IPC concept used in multi-core communication mentioned above, which frequently appears in the Linux kernel. In certain scenarios, these can be abstracted into models. Of course, the benefits of understanding the kernel are merely ancillary; the most important aspect is that the Linux kernel is deeply tied to processor cores, and Linux drivers are tied to SoC peripherals.
From this statement, can you sense that current embedded development involves physically connecting to peripherals through peripheral buses, writing C language programs, burning them to FLASH, and using them to drive sensors to achieve certain functionalities?
However, future embedded development will take place within the SoC, relying on the operating system, with development increasingly delving into the kernel and modifying Linux drivers to implement functionalities, leaving interfaces for application-level developments to be handled by CS, establishing connections at the business level, leading to a different division of labor.
Thus, the position of embedded application engineer may likely disappear in the future, reflecting a change in advanced levels.
The barriers for embedded development will continue to rise, creating a distinct divide and increasingly clarifying the blurred boundaries between embedded systems and CS.
For example, I have not used STM32 for a long time. I was fortunate to attend a nationwide conference organized by STMicroelectronics, where their engineers demonstrated their company’s visualization development operations. By simply clicking on a pin, selecting clock settings, and determining which peripherals to use, the system generates code. This kind of guided code generation is both convenient and standardized. At that moment, I wondered what the role of embedded application engineers would be. Why not just click a mouse and earn money? But this is impossible; when STMicroelectronics develops such tools, their chips sell well, making some people happy while others cry. Just like in the drama “The Legend of Zhen Huan,” where one sister kills another, this situation is similar; programmers are causing other programmers to lose their jobs, which is both amusing and cruel. Indeed, STMicroelectronics has already demonstrated the trend towards bare-metal development, and TI’s web-based configuration methods do not require downloading any software. Therefore, we can see that positions in upstream companies can significantly influence the fate of downstream companies.
As embedded processes continue to evolve, the learning curve will also increase rapidly. Since SoC is such a promising trend, can we start learning directly from SoC? However, one must understand that in this chaotic embedded era, we must learn step by step, starting from resistors and capacitors, then progressing to digital circuits and microcontrollers; software must begin with “printf hello world,” moving on to pointers and structures, and even learning C++; theory must progress from data structures to conventional algorithms; Linux systems must transition from proficient use to studying the kernel. None of these steps can be skipped. This is one reason why embedded systems are often seen as challenging, but as our ancestors taught us through dialectical thinking, “A blessing in disguise,” the high barriers to learning may ultimately lead to significant opportunities. Those who take the unconventional path often find the most rewarding experiences, and I believe you will eventually enjoy and appreciate your journey.
For those diagnosing the embedded industry, predicting its demise is less about static observations and more about understanding the dynamic nature of embedded systems. Just as a snake sheds its skin, leaving behind a dry layer of skin, the essence has already moved on. The concept of embedded systems will evolve with the times, adapting to new forms and realities, remaining alive and not fixed.
By observing the upstream semiconductor companies, we can discern future development paths, while the current demands for various positions do not reveal much. I forget who told me this, but upstream determines downstream, and there is a certain lag in this process. This lag provides you with time; otherwise, you will be ruthlessly eliminated.
Therefore, my advice for those working in embedded application roles in downstream companies is to prepare for the future; if possible, transition to systems development.
(3) A Reflection: The Mindset of Those Who Work Hard
I can proudly say that I am a relatively hardworking person. During my academic period, I engaged in very few entertainment activities, focusing primarily on coding and soldering while keeping an eye on industry trends, hoping that one day I could “fly ahead as a clumsy bird.” This mindset has somewhat led to a fixed way of thinking, including entering the job market. I cannot forget the effort I put in and do not want those efforts to go to waste by engaging in a completely unfamiliar position that is somewhat related, causing me to miss many opportunities. This sense of security I cling to is not ideal, and I sincerely hope that those diligent newcomers in the workplace can be bold enough to try new things, opening themselves up. After all, the perspective in school is narrow, and we often follow our own paths or hearsay, but the reality we face may differ significantly, with opportunities also varying. Letting go of what we have learned is challenging, but sometimes we must bravely take that step to experience new knowledge platforms. Ultimately, we discover that learning ability is key; what we learned previously is often interconnected, and there is no such thing as wasted learning. Perhaps I studied embedded software development in school, but the company requires me to learn about semiconductor IP knowledge, which has some relevance but should not be rejected. Instead, I should be bold in my attempts, as the company platform is more significant than my previous perspective. I initially worked hard with hopes for my current life, and now that I am on this platform, I must accept all realities and work diligently, rather than being unable to let go of the past.
-END-
1
“19 Essential Linux Commands You Must Know…”
2
“14 Common C Language Algorithms for Microcontrollers (with Detailed Code)”
3
“A Must-Read! A Master Summarized 10,000 Words of Essential Knowledge Points for Embedded C Language…”
This Week’s Live Broadcast | Click to View 👇
Monday | What is Artificial Intelligence Deep Learning?
1. What is Deep Learning?
2. How Much Do You Know About Artificial Neural Networks?
3. Are You Familiar with the Mechanism Behind Perceptrons?
Tuesday | Do You Really Understand What Compilers Do?
1. Don’t Recognize Any CPU Language?
2. Unfamiliar with the Development of Programming Languages?
3. Unclear About How Compilers Work?
Tuesday | The Relationship Between Pointers and Arrays
1. What Can Pointers Be Used For?
2. What Are Arrays?
3. Do You Understand the Relationship Between Pointers and Arrays?