Should I switch from MCU to Linux? Come in and see what the experts say
[Copy link]
Should I switch from MCU to Linux? Learn in 10 minutes
From the perspective of salary, assuming the questioner does not want to upgrade his academic qualifications, the recommended priority sequence is as follows:
1. Embedded (ARM+Linux) : It can be used for industrial robots, Internet of Things, and high-end 3C product design, but you need to take supplementary courses, mainly to supplement knowledge in signal processing. You don’t need to pursue depth, but you need to understand it. The salary level is determined by the characteristics of the selected company and industry, which is better than 3 and 4.
2. Embedded (FPGA, CPLD and other integrated circuit design): This path is basically the path of signal processing, which requires a deep foundation in mathematics, signals, analog electronics theory, etc. Generally, the starting point for a smooth job is a master's degree, but if you are interested in doing it, you can do it well with a bachelor's degree. In theory, salary is the first priority, but the difficulty of the work is also the first priority.
3. Single-chip microcomputer: Examples of related products: rice cookers, soybean milk machines, household appliances with low intelligence, etc., are highly homogeneous, there are many capable people, the competition is relatively fierce, and the product profit is low, resulting in poor salary and future salary increase. But it is better than PLC.
4. PLC: Sad PLC, the least recommended direction. People who work with PLC are usually in small and medium-sized automation companies or equipment departments of large companies. Overtime is common, and the salary is not too high, because people with secondary technical school level can take your job away. The added value of technology is very low now, and there is no good development if you change jobs.
Should I switch from MCU to embedded Linux? Well-known embedded engineer Huo Ge said: (Workplace tips from an embedded veteran)
Although Huoge is currently engaged in embedded development for Linux/Android, he also had about 5 years of experience in MCU bare metal and RTOS when he was studying. He also got some offers for MCU STM32 development in previous interviews, so today I would like to share some views on whether MCU should switch to embedded Linux.
1. Have you really decided to switch to embedded Linux?
Whether to switch from MCU to embedded Linux is a serious decision that affects your career development. Brother Huo cannot make a decision for you, but can only help you list the pros and cons. You need to make the most favorable decision based on your own environment (for example, are there many Linux embedded related positions in your city? Do you decide to leave your hometown to develop in Beijing, Shanghai or Shenzhen, etc.). Brother Huo's point of view is not that Linux embedded is definitely better than MCU development career development, but he just gives some opinions based on his own experience.
1. The biggest disadvantage of MCU development compared to Linux embedded is that the average salary of grassroots jobs is relatively low. I think this is the main reason why most MCU engineers want to switch to embedded Linux. The technology itself has its own advantages and disadvantages, but in terms of grassroots jobs, in the same city, the salary of MCU is 30% to 50% lower than that of embedded Linux. Maybe many people will compare the salaries of some high-paid bosses who make MCUs (such as Huo Ge of Wildfire, Zhou Ligong, etc.) or some company executives with engineers working in embedded Linux, proving that MCUs can also earn high incomes. But they all made the mistake of Tian Ji's horse racing, comparing other people's superior horses with your medium horses. Huo Ge believes that this kind of Tian Ji horse racing comparison is very unrealistic, and grassroots workers should be compared with grassroots workers of this level. According to Huo Ge's investigation, in the grassroots job market in Shenzhen, the starting salary for MCU (including RTOS) development is 6K-7K, and 15K is considered a high salary for ordinary people, and it is difficult to break through. There are offers for MCUs above 20K, but they are rare. At most, I have seen offers for MCUs of 25K, but those are all from famous companies, famous schools or other business backgrounds. Ordinary people really can't get them. In the field of embedded Linux/Android, the salary is relatively high. The starting price of 12K is normal. Generally, you can break through 15K after working for 2 years. There are also many people who break through 20K or even 25K in 3-5 years. If you work for more than 5 years in a first-tier local tyrant factory (Huawei, OPPO, VIVO, etc.), you can get 30K. If you become a module owner expert in a large mobile phone factory, you can break through 40K, but it is a bit difficult to go up. Overall, for grassroots workers of the same level, the salary of embedded Linux is still much higher than that of MCU development. MCU will encounter bottlenecks at 15K, and it is difficult to break through 20K. It is not difficult for embedded Linux to break through 20K, but it will encounter bottlenecks at more than 25K.
2. Are there many embedded Linux jobs in your city? I think this is another big issue that affects your decision. Most of us learn embedded Linux technology to do related work, not to cultivate our sentiments. However, according to Huoge's statistics, although the general salary of embedded Linux is higher than that of MCU, there are not as many jobs as MCU. Shenzhen is the city with the most embedded Linux job opportunities, but there seem to be more MCU opportunities. In Shenzhen, the number of MCU and Linux jobs is about 6 to 4. From the number of jobs in embedded Linux cities, it is Shenzhen> Shanghai> Beijing> Chengdu= Hangzhou= Suzhou> Dongguan (Huawei support)>= Zhuhai>= Nanjing= Guangzhou= Wuhan= Xi'an= Fuzhou= Xiamen> Foshan= Changsha= Tianjin= Hefei> Others. In other cities, I rarely know about jobs related to embedded Linux development. So if you want to consider changing careers, first consider whether you are willing to leave your hometown and work in the above cities. Otherwise, even if you have learned awesome Linux technology, you may not be able to find a suitable match locally and will have to continue to engage in microcontroller development.
3. Although the salary of single-chip microcomputer is relatively low, there are more job opportunities and it is relatively friendly to older job seekers . This is actually not contradictory. There are many small companies in various industries that make single-chip microcomputers (of course, there are also traditional home appliance manufacturers such as Gree and Midea, but emerging high-tech manufacturers such as Huawei and SenseTime rarely recruit single-chip microcomputers). The business is diverse and more people are needed, but small factories may not have sufficient funds and cannot afford high prices for talents. In addition, the threshold for single-chip microcomputer development is relatively low (not considering product stability, EMC and other concepts that people with work experience will naturally know, only referring to the training threshold for learning to use single-chip microcomputers to work and program), and the training cycle is relatively short (a sophomore student can work in one summer vacation), so there are still many people who can work in the middle and low end, which lowers the average salary. But this is like Foxconn, which recruits a lot of people but complains about the lack of people. The boss just doesn't want to raise the salary and wants to control costs. This is an ever-present contradiction between the lack of people but low salary. However, for older job seekers, since there are so many MCU positions, it is really difficult for many small factories to recruit excellent people with a high cost-effectiveness. In small factories, there is no HR to intervene in human resource planning and age echelon construction. On the contrary, the age limit is not strict. As long as older job seekers are not picky about salary, they can find a job. Therefore, compared with large Linux factories, they are more tolerant of age issues (probably because MCUs have a history and there are many older practitioners).
4. There are also some high-paying positions for MCU . In the eyes of MCU engineers, 20k or more is considered high-paying. Based on this standard, Brother Huo has also seen some high-paying positions, but there are some special requirements. A company that makes smart door lock STM32 RTOS has offered Brother Huo a 20K offer, mainly because the company hopes to recruit technical personnel with a 985 211 or above academic background, so that the communication may be more consistent, so the salary can be given to 20k. In addition, there is a star unicorn startup company that has offered a 25K MCU offer, but the prerequisite is to be able to develop MCUs in a Linux environment, and the interview is more difficult. The original 25K asking price exceeded their expectations, and they were unwilling to give so much. Later, Brother Huo kept them hanging for a week, lying that he had received an offer of the same price from Huawei, and they finally agreed to give a 25K offer. Brother Huo also learned that there are senior MCU engineers with an annual salary of 800,000 (mastering special certification standards in certain industries). But in general, it is not easy to get a high-paying offer for MCU, and getting it is not just because you have good MCU technology and strong bug-solving ability, but because of your background, education, other offers, special business competitiveness, etc. (For embedded business competitiveness, you can read Brother Huo’s previous article on embedded competitiveness). These special businesses, diplomas, and backgrounds are not easy to obtain by spending time reading books and learning to write code. If you can get a technology by spending time and effort, it is not a threshold technology.
After listing the above points, I believe you can make a decision whether to switch from MCU development to embedded Linux.
2. What are the similarities and differences between MCU and embedded Linux development?
1. The advantages of switching from MCU to embedded Linux mainly lie in the proficiency of C language programming and rich debugging experience of low-level software and hardware interfaces. Because the Linux kernel itself is written in C language, most of the Linux low-level applications are also written in C language. Generally, those with experience in MCU development should not have a problem with C language, so in the process of switching, there is no need to consider the language switching. Of course, if you have not systematically learned data structures (Brother Huo believes that data structures are essential to familiarizing yourself with C language, even for MCUs, you must understand data structures), you may need to make up for it. In addition, it is better to have experience in real-time operating system development such as uCOS FreeRTOS, at least you will not be afraid when looking at large-scale C language code (in fact, understanding the uCOS kernel does not mean that you can master the Linux kernel immediately. The Linux kernel is really too complicated and the design concept is also very different). In addition, rich experience in low-level debugging and register configuration of MCUs may help you quickly locate some low-level problems when learning Linux embedded development, saving some time.
2. Converting MCU to Linux embedded system requires familiarity with a development environment with different styles. For most MCU engineers, they mainly develop MCU programs using IDE environment on Windows (it is not ruled out that some companies have already used Linux to develop MCUs). They are less exposed to Linux systems such as Ubuntu, so the first hurdle you have to overcome is not the Linux kernel source code, but how to use Linux systems such as Ubuntu. Because software development in various Linux systems such as Debian, Ubuntu, CentOS, etc. is mainly done through command line operations, rather than mouse interface clicks. Moreover, the application software in the Linux system is not integrated for you like the IDE in Windows, which can be used with just one click. Linux contains many compilation scripts such as Makefile, various services such as Samba, SSH Server, and various compilation and linking tools such as arm-linux-gcc. They are like the various components in the IDE software. They need to be reassembled and used by yourself, and there may be various environment and even compilation problems when using them (this is the case with open source software), which requires a lot of time to debug yourself. Therefore, for Linux beginners, even if you have rich experience in microcontroller C language, it is time-consuming and you need to overcome psychological barriers. The Linux system development environment is like an unruly horse that can only be tamed to show its value, while the Windows system development environment is more like an obedient ordinary horse.
3. The control level of embedded Linux development code is much lower than that of MCU development. MCU to Linux needs to adapt to how to develop in this insecurity of low control. MCU development, including RTOS, generally has a maximum of tens of thousands of lines of code. Even if you don't read every line of code, you can basically accurately control each module and find out where the bug is. As a developer, it is easy to locate. For embedded Linux development, the Linux kernel alone has millions or even tens of millions of lines, not including various open source libraries at the application layer that you are not familiar with, which makes it impossible to control most of the code. The development mode of embedded Linux is to develop drivers or applications in this situation where most of the code is not developed by you and you cannot control most of the code. You often need to search and ask people for things you are not familiar with. This development mode will put people in a valley of uneasiness. You don't know the implementation details of many functions you use, and you may only have a rough understanding of the working mechanism. In this mode, development requires good search, communication, and teamwork skills. It is no longer possible to control the whole situation by yourself like MCU and develop blindly. This uncontrollable insecurity is what MCU engineers need to adapt to most in the process of developing into Linux embedded engineers.
4. Embedded Linux development requires a big picture view, and you don't have to get lost in the jungle of details and can't find the direction and exit . Many MCU engineers have a habit of thinking. When programming, they like to pay attention to the working principle of each register, the implementation details of each function, and every if else. This will be very time-consuming and counterproductive in Linux embedded learning. It is good to pay attention to details, but when the system is large to a certain extent, people who pay too much attention to details often find it difficult to control the system. I have seen many beginners who have to struggle for a long time with each register and each way of writing link scripts. The chip startup method is even more rigid, taking the 2440 startup process as the only truth of chip startup, and applying it to other chips everywhere. Little do they know that many things are some habitual practices agreed upon by humans. Each company's chip has its own characteristics. The process is dead, but people are alive. Master the big picture view, let yourself quickly familiarize yourself with the knowledge of the entire system, and many habitual things in the details will naturally understand, and the control of the entire system will be high. When you encounter specific details that hinder your progress, try to deal with them. Control doesn't mean you know the meaning of every line of code and every register, but you can make the entire system run the way you want.
3. What basic knowledge do you need to learn to switch from a single-chip microcomputer to embedded Linux? After so much talk, it’s time to get down to business. What do you need to learn to switch from a single-chip microcomputer to embedded Linux?
If there is no such paragraph, I am afraid that you will pick up a book on Linux kernel architecture and implementation immediately after you make up your mind to change careers, thinking that it is just like learning uCOS and other RTOS systems, which are all C language codes, and then you will be confused and give up from getting started. In fact, I made similar mistakes when I first learned Linux embedded system, so I summarized some experiences and lessons.
1. You need to spend some time to familiarize yourself with how to use the Linux system for programming and development . I believe that many students grew up using Windows computers. Before learning computer programming, they should not have been exposed to Linux systems such as Ubuntu. This system is not like Windows, which can be obeyed by clicking the mouse. It requires various command line operations. In addition, there are various services and application tools in the system that you need to configure according to your needs. Therefore, learning embedded Linux development is not about rushing into the ocean of Linux kernel code, but about using the Linux system first. You can refer to books such as "Bird Brother's Linux Private Recipes" on how to install and use the Linux system to learn how to use the command line. However, Brother Huo believes that learning should be targeted. If you learn each command page by page from "Bird Brother's Linux Private Recipes", it will become boring after a few days. Therefore, Brother Huo recommends that students with experience in single-chip microcomputer development should first learn how to build your single-chip microcomputer development board cross environment on the Linux system, compile a bare metal LED lighting program (without running the Linux kernel), and burn it through the tools provided by the development board manufacturer. This is not a difficult thing. There are already many articles on the Internet about how to cross-compile MCU programs under Linux system, especially for the stm32 series. You can refer to other people's articles and do it again. In this process, you will be familiar with various commonly used commands, shell, arm-linux-gcc cross-compilation tool chain, Makefile (you can refer to Chen Hao's article separately), and other knowledge related to the Linux programming environment, thus starting to enter the world of Linux.
2. You need to know how an embedded Linux system runs and what components it generally consists of. I believe that most people switch to embedded Linux development not to develop microcontroller programs on the Linux system, but to develop Linux drivers or applications. After taking the first step, don't worry too much about how to write those compilation and link scripts, but focus on Linux system development as soon as possible. To learn embedded Linux system development, you must first know how a Linux system runs and how to set up a Linux system environment on the development board. This involves a series of components such as bootrom, bootloader, uboot, dts, Linux kernel, cmdline, rootfs, and various different methods such as nand boot and nor boot. Know how a Linux embedded system works, and then further modify and add your own drivers and applications. There are many practical things here, and you may need video materials to take you through it before you can get started quickly. Brother Huo watched Teacher Wei Dongshan's embedded Linux videos before. There are a total of one, two, three, and four episodes. There are free trials and paid ones. You can contact the seller directly on Xbao to find out. Brother Huo will not post advertising links. There are other videos, but I won’t recommend any that I haven’t watched. When learning embedded Linux, you need to read books to learn theoretical knowledge, but you still need video materials to help you get started quickly with practical knowledge. Reading and practice should be a gradual process.
3. You can try to develop some simple Linux applications and drivers. After completing the first two steps, I believe you have a certain professional understanding of embedded Linux development. In the field of embedded Linux learning, Brother Huo prefers to learn by doing, 60% practice + 40% theory. Because many things related to the system environment in embedded Linux are not the strict theoretical formulas in books, it is difficult to find rules by reading books, and there is a whole set of jargon in the Linux kernel (what does GNU mean? Search it yourself) world. Those technical experts who write Linux kernel and driver books cannot explain all the jargon to you. So, if you open the classic books of big cows such as "Advanced Programming in Unix Environment" and "Linux Device Driver" directly without any use and development experience, it is easy to make you confused. Brother Huo suggests that you follow a video tutorial, such as Teacher Wei Dongshan's embedded Linux video, write a simple driver and application from scratch, run the driver and application code you wrote, and light up an LED lamp. Don't worry about how to implement the initialization, registration and other framework functions you call in the Linux driver. Through the process of practice, you will become familiar with the operating environment of the entire code and various jargons in Linux development (system calls, vfs, etc.). This is also a way for you to get positive feedback from learning step by step, and enhance your sense of achievement and learning confidence. In fact, Linux driver development itself is not difficult (the difficulty is no more than the formulas in your complex function textbook), nor is it mysterious. It's just that it has a whole set of jargon terms that can easily confuse beginners. If you are familiar with this set of jargon and get rid of fear, an ordinary undergraduate with normal IQ should be able to master it.
4. You need to supplement some theoretical knowledge of computers. According to Brother Huo, most MCU engineers are from electronics, communications, automation, machinery and other majors, and very few are computer majors. These majors are relatively lacking in basic theoretical knowledge of computer majors, such as data structure, operating system, computer composition principle, computer network, algorithm, basic principles of compilation and linking, database, etc. Supplementing theoretical knowledge is a long process (may take 2-3 years). It is not necessary to wait until all the professional theories of computers are learned before looking for a job. You can supplement basic knowledge while interviewing and looking for a job, and test your basic knowledge at the same time. These basic knowledge can not only improve your technical skills, but also help you pass the written test and interview, and determine whether you can break through 20K salary in first-tier cities. After having the basic knowledge of computer majors and having some experience in Linux driver development, it is necessary to learn the Linux kernel, but beginners do not need to rush into the Linux kernel source code. The kernel is still quite a lot and quite difficult. You have to spend time reading books and looking at the code slowly. It is impossible to learn quickly, but the Linux kernel skills can still improve your salary competitiveness.
IV. Advice for career changers with work experience
1. For those who have a job, your advantage is that you have a guaranteed job and income, but your disadvantage is that you don't have enough free time to study. With your current job, you don't need to rush to find a new job. You can maintain a good attitude, not be arrogant or impatient, and you can learn while looking for a job to find a suitable job. Of course, people who have a job don't have free time. If the new things you want to learn are not directly related to your current job content, Brother Huo suggests that you can first choose a job with less overtime, so that you can free up your spare time after get off work to learn new knowledge of embedded Linux. People who have a job have some small savings, but lack time. In terms of learning, you can buy some cost-effective paid videos to speed up your entry and learning progress and save precious time. This is also a way to exchange money for time. In general, you don't need to learn to be proficient before going out to find a job. Once you can self-correct (this term comes from a TED speech on how to quickly self-study) and can do some work, you can go out for interviews and find related jobs. Linux embedded learning is mainly based on general basic knowledge. The business knowledge related to audio and video and communication protocols in the driver can be supplemented by finding related jobs.
2. How to get a job in embedded Linux development through social recruitment when you only have experience in MCU but no experience in Linux development? This is a headache for job seekers who are looking for relevant work backgrounds.
Brother Huo has the following suggestions:
First, check whether the company has a Linux-related department and development plan, and take the initiative to try to transfer internally.
Second, see if you can suggest to the company's technical director to migrate the microcontroller development environment to the Linux system, and develop the microcontroller in the Linux system environment, so that at least you will have the opportunity to use the Linux system at work.
Third, you can try to interview some companies that develop MCUs in Linux environment. After the interview, ask the interviewer whether they develop MCUs in Linux environment. If so, you can join a company that develops MCUs in Linux and continue to work on MCUs for a while, and get familiar with Linux at work.
Fourth, try to interview some bootloader or firmware development related positions in companies that really do Linux system development, because bootloader and storage controller, power management and other firmware codes have a lot of relevance to single-chip bare metal rtos development, and even ARM SOC has single-chip cores and related firmware for controlling wifi, storage, power sleep wake-up and other related functions, which can ensure that you can make certain output contributions in the new job, rather than being a complete learner. Fourth, try to interview some real Linux companies with high mobility and high turnover rate. Such companies can be described in one word: "lack of people". Brother Huo used to work in an IC original factory in Zhuhai. Due to the small number of related practitioners in Zhuhai, many fresh graduates are unwilling to come to small cities for development. In addition, the company's performance in recent years has been poor and the turnover rate is high, resulting in a lack of people in the company and it is difficult to recruit people. Therefore, the recruitment standards were later relaxed and they were willing to train social recruits who only had single-chip microcomputer experience but no Linux experience. Of course, the well-known large company in Shenzhen where Brother Huo works now has a large base of employees, and the company's brand and remuneration are very competitive, so the competition is quite fierce. Although they claim to be short of people (in fact, they are too picky in recruiting), they generally do not give opportunities to job seekers without Linux experience.
Finally, in the process of learning Linux embedded, it is best to record the problems encountered and the codes written in a technical blog and GitHub, and paste the relevant links on your resume. This is also to prove to the interviewer that you really have a certain understanding of embedded Linux. Only after reading your blog and GitHub, the interviewer can have a further understanding of your technical level and decide whether to give you a chance.
5. Advice for students who want to change careers
For students in school, you have more freedom in time, but lack money and a secure job.
Of course, time is like toilet paper. It seems like there is plenty of it, but it’s gone as time goes by. So even if you have plenty of time, you still have to plan it well and try to learn as much as possible.
Since students are short of money, I don’t recommend spending tens of thousands of dollars on offline embedded training. In fact, the content of the training is all embedded entry-level knowledge, and the quality may not be as good as Wei Dongshan’s embedded Linux videos that cost a few hundred yuan. In addition, video tutorials may be more flexible in terms of time than training.
The advantage of students in school is that they have no industry-related experience. During the campus recruitment, your industry-related knowledge will not be tested, but more emphasis will be placed on the basic computer knowledge (Brother Huo even got an offer from an IC manufacturer's Linux based on his written test scores in operating systems, C language, and data structures, even though he had basically no Linux development experience. Of course, there was still more than half a year after the campus recruitment, so I bought Wei Dongshan's paid videos to make up for the relevant knowledge). Therefore, students in school should take advantage of this precious time to lay a solid foundation for the fourth point of basic knowledge mentioned by Brother Huo in the previous section, so that they can focus on learning business knowledge after work, get promoted and get a raise faster, and don't have to go back to school because of weak basic knowledge.
In addition, students may participate in various MCU embedded competitions. During the competitions, they may win many awards and be praised by teachers and classmates. But remember to be modest and not arrogant. Don't think you are great just because you master two more technologies than ordinary students (your competitors in future interviews are not these students who have no technology at all). Don't be proud of a few awards and fail to calm down and learn basic knowledge such as data structure and operating system principles. If you don't publish high-level papers in well-known journals, or win high-quality awards with scores and rankings in internationally recognized ACM, Kaggle, ISLVRC image competitions, other domestic competition awards are not very convincing in interviews and actual work. Interviewers prefer students with solid basic skills and strong plasticity, rather than students who have won a lot of domestic awards but know nothing about concepts such as time complexity, linked list stack, mmu virtual address space, etc.
So can other majors switch to embedded systems? How can they do so?
A few days ago, a friend asked in the background that he was a student majoring in mechanical engineering and wanted to switch to embedded systems. How should he learn? Today we specially made such a topic, hoping to help those friends who want to switch to the embedded system field!
The person in charge is confused, but the bystander can see clearly. Regarding the matter of changing careers, let's first listen to other people's opinions:
From mechanical to embedded, I don't think it's a career change, but an expansion of my professional field. After all, embedded software is not a purely theoretical thing. Most of its functions are realized through machinery. Take an extreme example. What knowledge do you think is needed to design a robot? Is mechanical design and embedded software enough? Far more than that. Learning embedded software design does not mean giving up mechanical design. It's good to have this idea. It's not so good to do mechanical work purely. The future trend must be compound. First of all, from the perspective of personal development, the overall salary and benefits of the software industry (embedded/communication/Internet) are better than those of the traditional mechanical industry. If you have perseverance and determination, and can take the initiative to learn, in order to improve your living standards, it's not a bad idea to change industries. From the perspective of industry development, as far as I know, the research and development of high-precision CNC machine tools in China has always been very weak. Research in this area requires cross-industry talents. It would be great if there is such an opportunity. In addition, research in the field of robotics (automated production) is also on the rise, and it is also good to have a cross-industry technical background. Embedded software development will be more popular in the future, and its application range is relatively wide. But it is not recommended to completely abandon the original work field and switch to embedded. It's best to find some intersections so that your career has fewer ups and downs.
I majored in mechanics, but I also like electronics and software. I learned microcontrollers and drawing circuit diagrams, so I have some experience in this area. If a person who majored in mechanics wants to switch to electronics or software, the transition is relatively large, and it is best to have someone to guide you. Software requires a deeper understanding, so if you want to develop in this direction, you need to learn a lot. I think if you like it and the conditions in all aspects are suitable, you can develop in this direction. If you feel that your expertise in the mechanical design industry has not been fully utilized, it is recommended not to change careers. If you have the ability but feel that the work is difficult, then don't change. These days, you will encounter difficulties in any industry. It depends on how long you can persist in the face of difficulties. After comprehensive analysis, if you feel that your ability cannot persist any longer, it is recommended that you change immediately without hesitation. Of course, there will be difficulties in crossing industries.
Of course, the above suggestions are just for reference.
To become an embedded engineer, you can take a look at the following suggestions:
1. Embedded technology involves a lot of basic knowledge of C language. You need to know the basic syntax of C language, what is a structure, what is a union, and what is the difference. You don’t need to memorize some things for the second-level exam because they are rarely used in practice.
To learn C++, you need to know what classes are, how to define them, inheritance, and interfaces. You need to have a deep understanding of them. Of course, basic syntax is also essential.
You should also know the basic principles of operating system principles, such as time slices and task scheduling.
How to use basic Linux commands (you must know how to use the vi editor, because it is the only one you can use when modifying files in the terminal). Many of us are now accustomed to using the mouse and seldom use commands. We must change this habit when we learn to embed Linux. Linux uses commands for operation, firstly, it is highly efficient, and secondly, it is very powerful, far beyond the reach of the graphical interface. In fact, all the operations we use the graphical interface must be converted into commands and passed to the hardware.
You need to know the management of Linux file system, which directory stores what, what is its use, file permission management, etc. You also need to know something about Shell programming. Here I recommend a tutorial, Zhou Chaojian's Shell Programming, which has only seven or eight lectures, and is very comprehensive. Beginners can just read the first four lectures.
2. Don't expect to understand what a book means in one go, and don't memorize it by rote. It doesn't matter if you don't understand it. You can find it when you encounter it later. You will remember it when you encounter it more often, and forget it when you encounter it less. Also, don't read the Linux kernel source code directly. Reading something that you can't figure out even if you hit your head against it will discourage beginners. You should learn to make an LED today, a serial port tomorrow, and hardware encoding and decoding the day after tomorrow.
3. You can choose not to receive training, but you must buy a development board. If you want to learn embedded systems, you must buy a learning board. Today's development boards are very cheap, which reduces the financial burden for beginners. No matter how many videos you watch or how many books you read, it is better to try it yourself. Things that look simple may encounter many problems when you do them. When you encounter problems, find the causes and solve them. Only in this way can you learn something. I remember the first time I wrote an LED driver, I wanted to try it myself. Someone on the Internet had written related codes, but when I tried it myself, there were many problems. It took me a whole day to light up the LED. So don't aim too high and aim too low.
As for training, there are many training institutions now, the teaching is good, the teachers are also very good, but there is a problem, too centralized, and students do not have many opportunities to practice. I remember that our company hired an employee who trained in a training institution in Beijing for half a year, costing more than 10,000 yuan, but he did not feel very high after he came. When asked what he learned, he said the basic knowledge I mentioned earlier, and he still did not know a lot of things. He followed the book to make a helloworld module driver but it took him two days to get it done. It's not that the training is bad, but in my personal opinion, the effect is not very good. Remember: only things you have done yourself are yours.
4. Don't aim too high, be down-to-earth. For beginners, there is a little suggestion. When we get a development board, we are very excited and excited. Naturally, we have a lot of ideas. We want to use the development board to realize our own ideas, but we don't know where to start. Then we post a message in the forum, "How to realize that thing? Which hero can tell me in detail, please!" Then wait for others to reply. When no one replies, complain. It is good to have ideas. There are also prerequisites for us to realize our own ideas. First of all, do we understand this part of knowledge? If you don't understand, go to Google (it's best not to use Baidu, it's not easy to use). If you understand it, you will know roughly how to do it. If you encounter problems again, post again, so that we can show that we have level. For example, if you don't even know what a serial port is, you ask how to do serial communication. Even if someone gives you the code, you don't understand what's going on.
5. Read more code, write more code, and practice makes perfect. Read more code, and understand the meaning of the code. Write more code and practice more.
|
提升卡
变色卡
千斤顶
京公网安备 11010802033920号
