10 skills needed today for an embedded system developer (free translation with comments)
Industry experts are urging embedded system developers (BP) to leave the comfort zone and acquire new skills in order not to lose relevance in the profession.
If we look at the situation in 1980, the guy (and mostly the guys do the controllers), who developed the mixed signal processing scheme, the guy who connected the MK, the guy who wrote the assembly language code, and the guy who carried the prototype out ( Probably, I mean debugging - the comment of the translator), was the same person (I am one of them, although, of course, it started in the USSR much later than 1980 -). All this was largely done by one engineer.
As the embedded systems became larger and more complex, and millions of lines of code began to ship with the device (Jack Hansley in his article recalls the time when the full BIOS source code was supplied with the IBM PC), it was time to divide the hardware development, development firmware and software development in a single device.
')
In many large companies, it still remains so. But it seems that the pendulum has swung back, as in large companies, consolidation of roles is occurring and developers are again in vogue, who are fluent in both hardware and software, and are trying to do more with less. Accordingly, a growing percentage of engineers say that they work both on the hardware and software levels, and the share of generalists exceeds the share of narrow specialists. (Actually, universals did not disappear anywhere, just some time in the industry the opinion reigned that the principle of decomposition and specialization is a silver bullet and allows us to achieve good results by the team of mediocrities - nn).
Since we do not want to keep up with progress in the field of BP, how to determine which skills we can acquire or develop are the most relevant today?
The EE Times magazine turned to 9 professionals in BP (apparently, they had a failure in the address book, nothing else that they didn’t contact me, I can’t explain - nn) and recruiters and asked them to tell what they think about the most important things needed by a modern BP engineer.
Although opinions on the importance of specific skills were divided (I would be surprised if they were NOT divided -), all respondents agreed on one thing: an engineer should never stop learning. (This is followed by recommendations from various engineers with work experience in BP of about a dozen years — individual work experience of everyone, not all ten at once —).
1. Learn the technologies that are associated with the use of the Internet.
If you can make a mixed signal processing circuit and write code in C or C ++, then you already know a lot of useful things in BP, but just writing C code is not enough in many cases. (This is probably a call for the study of libraries - nn).
Using technologies that make Internet connections to your devices possible is a big plus for an engineer’s career. In fact, I am currently working on several initiatives that include the implementation of “virtual” XML in BP. (I also made such systems and was amazed at the simplicity and ease of implementation of such things based on standard software modules, but if you also understand what happens at the same time ... - nn). We use this technology to provide offline processing of meta-data transactions from widely differing devices connected using standard low-level protocols and proprietary protocols to influence the network abstraction layer. (I can’t say that I understood this phrase to the end, maybe readers will have better luck - nn).
I guess it should be something like P & P technology for small network devices. (By the way, the Intel Edison model made a significant step in this direction - nn).
2. You have a search engine, use it.
Do not waste your time on the invention of the wheel, use open source. I suspect that someone has already written almost any piece of code you could have dreamed of. (I’m not sure that everything, but a lot of it is really written, although a large number of software has a FATAL DEFICIENCY - nn).
There are exceptions, of course, if you are doing breakthrough research. But most of us work to solve everyday problems, so use all the code available via the Internet.
Do not sit in your corner, trying to solve puzzles by experimenting. You must be a member of the community. Help people when you can, and they will most likely do the same. (It is unlikely that these will be the same people - nn). Open source is an amazingly powerful tool that only works if people collaborate.
3. Learn something new outside of your comfort zone.
Although following the latest trends is useful and almost always fun, the greatest benefits are achieved by deepening or expanding the field of knowledge. Accept the challenge to learn something outside of your comfort zone, such as hardware, your company's domain experience, or project management. (Probably, the respondent puts a different meaning on the term project management - nn).
Focus on improving your core skills and inherent benefits, but do not forget to work on interacting with the people around you, better understanding their motives (Thank you, captain - nn). Engineering is fundamentally a human activity, and the key task is to maintain a balance of interests. Too many young engineers focus too much on either interacting with people or designing. I know this is not easy, but you can actually do more good by working on both sets of skills.
4. Make friends with the RTOS.
Engineers who have mastered the formal structural development processes when using RTOS are in great demand and claim large salaries, due to the fact that they realized the need for a certain rigor in designing critical safe products and deeply accepted the idea of ​​parallelism. Given that at any time the CPU can start another task, they know how to protect shared resources, while maintaining performance. (I watched a lot of code for the RTOS and far from all of it corresponds to the last phrase. However, the use of RTOS even in small projects can really be very useful and does not require any significant development costs and significant resources when used - nn).
So I would like to encourage engineers who work with small devices that did not work with RTOS to get some practical development experience under them - be it VxWorks or Micrium (or FREERTOS - nn). I am also starting to see the possibilities of application in the developed devices of embedded Linux systems, since Linux (as a whole) is a very scalable operating system. You can trim it to a bare sheduler, and then download it on any device, and you can modify even parts of the kernel for more optimization and functionality.
5. Diversify your skills and move up the stack.
If you are still working with bare code or on small microcontrollers, I advise you to work with Linux drivers, which will make it easier for you to switch to Android later. (I didn’t quite understand why I would need Android, but as they say, don’t promise the prison and the bag - np). And, although this may be less significant - if you are used to working in large systems, try working with bare code.
Move up the stack: make a mobile application or master the back end of the server. This will give you a new knowledge and awareness of perspective.
And get familiar with the open source hardware. The projects that I did 8 years ago required me to create my own HW and the like, so I could not concentrate on the actual development of the algorithm. Today there are a lot of finished boards (probably referring to development kits - nn), which allow me to focus on a unique part of the development.
Of course, this may make me think that all my past development of firmware has become unnecessary and working with the boards was not as fun as before, but we should accept changes to the rules of the game. Unfortunately, this at the same time means that I meet fewer and fewer people with specific skills (apparently meaning the ability to develop from scratch - nn), and those who are, are literally dying out.
6. Know the familiar software perfectly, but do not forget about the new compilers.
It's a good idea to know several languages ​​(I hope programming languages, otherwise I should have left the profession - nn), some recommend learning one new language every year. (Not sure if this is a really good idea, I constantly confuse the JAVA and C ++ paradigms). However, while pure programmers need to learn languages ​​according to their specific needs, embedded engineers need to look wider. A deep understanding of C or C ++ is critical, but knowledge of the newest fashion language (I alone think of C ++ 14? - nn) is not as important as the new fashionable processor technology.
What is important to know about processors, that they are the basis for BP. Since we have limited system resources, we need to understand what we really have at our disposal. A new and elegant language, such as Go, can be incredibly powerful, but it is possible that it will not work in our system with limited resources. (By the way, I was quite amazed how compact the C ++ constructs are, at least under the IAR for the ARM architecture. Nothing superfluous and the entire class syntax and everything else just evaporates in the final code. So even with Go, everything may not be so bad - nn).
After all, you need to know a little bit about everything and everything about something. Expanding existing knowledge is important, but equally important is learning new things that will make you an expert in related fields.
7. Do not be afraid of free software.
There are thousands of software packages that customers want to integrate into their systems, so BP engineers should feel comfortable in this area.
I also want to emphasize that you should avoid closures in one area, because skills almost inevitably become obsolete and impede professional growth. And make sure you understand both the hardware and the software equally; such engineers are highly appreciated.
8. Develop a system of engineering thinking.
It is critical for BP to be systemically oriented. I saw a number of projects that were badly affected by the fact that there were no clearly defined baseline requirements, development strategies, and compliance checks in the early design stages. And every engineer must acquire good project management skills, in case you are asked to make a commitment on time. Having the opportunity to reasonably explain technical and project risks will serve you as a good help in your career.
9. Develop communication skills (both in words and in graphics).
Engineers of all types must be able to effectively express their thoughts and ideas, and often the best way to do this is in a graphical way. Too often, I asked junior engineers to explain the concept of the device and watched them wander around the bush, unable to focus on what they were trying to explain. (By the way, do not forget about the effect of a rubber duckling - nn).
We are used to using flowcharts to explain concepts. Maybe they are somewhat outdated today, but every engineer should have the ability to use flowcharts, state machine diagrams as a basic skill, as well as any other tool that can help in the transfer of concepts. Especially if they try to explain how something works.
Can you imagine a task for a developer who writes software for a controller that explains how the machine that the controller should operate using a text document works? (I can, I have seen such tasks, and even worked on them - nn).
Mindmapping is one of my favorite methods of capturing and visualizing my ideas and thoughts, and I use the iThoughts, MindMapping app for iPad almost every day. (And I do not even know what it is - nn).
10. Master the wireless connection.
The only thing I would recommend to the VZ engineers to master in the next 1-3 years is wireless communication, in particular, Wi-Fi and / or BLE.
The main (and sometimes the only) way to interact with embedded devices goes to the user's smartphones, at least in the field of consumer electronics. Household appliance companies understand that a smartphone is much better adapted to the user than the tools of most embedded systems by themselves. And other industries and manufacturers of end products tend to think about this. (Of course, if you have a final budget, otherwise you can afford your communication devices - nn).
Our embedded systems will need to interact with the application on a smartphone or internet services based on them in order to do something — communicate with the user, get a firmware update, fix a problem, etc.
It may be a bit early to say that WiFi and BLE will soon be as common as UART today (UART yesterday, today USB, but this is a personal opinion expressed in a private conversation - nn), but the trend is obvious and in any case it is enough A good tool to have in your bag of tools.
From the translator:
One should not write in the comments that these 10 points do not contain anything new (I could not resist in one place, but did not delete) - in the end, all mathematics is a tautology. In the end, all the recommendations come from people with rich experience who occupy a certain place in the BP industry, and only therefore deserve attention.
But if someone writes in the comments about what else the BP engineer needs and was, in his opinion, undeservedly bypassed in the article, then this will surely earn the gratitude of the readers and the advantages to karma.
If we look at the situation in 1980, the guy (and mostly the guys do the controllers), who developed the mixed signal processing scheme, the guy who connected the MK, the guy who wrote the assembly language code, and the guy who carried the prototype out ( Probably, I mean debugging - the comment of the translator), was the same person (I am one of them, although, of course, it started in the USSR much later than 1980 -). All this was largely done by one engineer.
As the embedded systems became larger and more complex, and millions of lines of code began to ship with the device (Jack Hansley in his article recalls the time when the full BIOS source code was supplied with the IBM PC), it was time to divide the hardware development, development firmware and software development in a single device.
')
In many large companies, it still remains so. But it seems that the pendulum has swung back, as in large companies, consolidation of roles is occurring and developers are again in vogue, who are fluent in both hardware and software, and are trying to do more with less. Accordingly, a growing percentage of engineers say that they work both on the hardware and software levels, and the share of generalists exceeds the share of narrow specialists. (Actually, universals did not disappear anywhere, just some time in the industry the opinion reigned that the principle of decomposition and specialization is a silver bullet and allows us to achieve good results by the team of mediocrities - nn).
Since we do not want to keep up with progress in the field of BP, how to determine which skills we can acquire or develop are the most relevant today?
The EE Times magazine turned to 9 professionals in BP (apparently, they had a failure in the address book, nothing else that they didn’t contact me, I can’t explain - nn) and recruiters and asked them to tell what they think about the most important things needed by a modern BP engineer.
Although opinions on the importance of specific skills were divided (I would be surprised if they were NOT divided -), all respondents agreed on one thing: an engineer should never stop learning. (This is followed by recommendations from various engineers with work experience in BP of about a dozen years — individual work experience of everyone, not all ten at once —).
1. Learn the technologies that are associated with the use of the Internet.
If you can make a mixed signal processing circuit and write code in C or C ++, then you already know a lot of useful things in BP, but just writing C code is not enough in many cases. (This is probably a call for the study of libraries - nn).
Using technologies that make Internet connections to your devices possible is a big plus for an engineer’s career. In fact, I am currently working on several initiatives that include the implementation of “virtual” XML in BP. (I also made such systems and was amazed at the simplicity and ease of implementation of such things based on standard software modules, but if you also understand what happens at the same time ... - nn). We use this technology to provide offline processing of meta-data transactions from widely differing devices connected using standard low-level protocols and proprietary protocols to influence the network abstraction layer. (I can’t say that I understood this phrase to the end, maybe readers will have better luck - nn).
I guess it should be something like P & P technology for small network devices. (By the way, the Intel Edison model made a significant step in this direction - nn).
2. You have a search engine, use it.
Do not waste your time on the invention of the wheel, use open source. I suspect that someone has already written almost any piece of code you could have dreamed of. (I’m not sure that everything, but a lot of it is really written, although a large number of software has a FATAL DEFICIENCY - nn).
There are exceptions, of course, if you are doing breakthrough research. But most of us work to solve everyday problems, so use all the code available via the Internet.
Do not sit in your corner, trying to solve puzzles by experimenting. You must be a member of the community. Help people when you can, and they will most likely do the same. (It is unlikely that these will be the same people - nn). Open source is an amazingly powerful tool that only works if people collaborate.
3. Learn something new outside of your comfort zone.
Although following the latest trends is useful and almost always fun, the greatest benefits are achieved by deepening or expanding the field of knowledge. Accept the challenge to learn something outside of your comfort zone, such as hardware, your company's domain experience, or project management. (Probably, the respondent puts a different meaning on the term project management - nn).
Focus on improving your core skills and inherent benefits, but do not forget to work on interacting with the people around you, better understanding their motives (Thank you, captain - nn). Engineering is fundamentally a human activity, and the key task is to maintain a balance of interests. Too many young engineers focus too much on either interacting with people or designing. I know this is not easy, but you can actually do more good by working on both sets of skills.
4. Make friends with the RTOS.
Engineers who have mastered the formal structural development processes when using RTOS are in great demand and claim large salaries, due to the fact that they realized the need for a certain rigor in designing critical safe products and deeply accepted the idea of ​​parallelism. Given that at any time the CPU can start another task, they know how to protect shared resources, while maintaining performance. (I watched a lot of code for the RTOS and far from all of it corresponds to the last phrase. However, the use of RTOS even in small projects can really be very useful and does not require any significant development costs and significant resources when used - nn).
So I would like to encourage engineers who work with small devices that did not work with RTOS to get some practical development experience under them - be it VxWorks or Micrium (or FREERTOS - nn). I am also starting to see the possibilities of application in the developed devices of embedded Linux systems, since Linux (as a whole) is a very scalable operating system. You can trim it to a bare sheduler, and then download it on any device, and you can modify even parts of the kernel for more optimization and functionality.
5. Diversify your skills and move up the stack.
If you are still working with bare code or on small microcontrollers, I advise you to work with Linux drivers, which will make it easier for you to switch to Android later. (I didn’t quite understand why I would need Android, but as they say, don’t promise the prison and the bag - np). And, although this may be less significant - if you are used to working in large systems, try working with bare code.
Move up the stack: make a mobile application or master the back end of the server. This will give you a new knowledge and awareness of perspective.
And get familiar with the open source hardware. The projects that I did 8 years ago required me to create my own HW and the like, so I could not concentrate on the actual development of the algorithm. Today there are a lot of finished boards (probably referring to development kits - nn), which allow me to focus on a unique part of the development.
Of course, this may make me think that all my past development of firmware has become unnecessary and working with the boards was not as fun as before, but we should accept changes to the rules of the game. Unfortunately, this at the same time means that I meet fewer and fewer people with specific skills (apparently meaning the ability to develop from scratch - nn), and those who are, are literally dying out.
6. Know the familiar software perfectly, but do not forget about the new compilers.
It's a good idea to know several languages ​​(I hope programming languages, otherwise I should have left the profession - nn), some recommend learning one new language every year. (Not sure if this is a really good idea, I constantly confuse the JAVA and C ++ paradigms). However, while pure programmers need to learn languages ​​according to their specific needs, embedded engineers need to look wider. A deep understanding of C or C ++ is critical, but knowledge of the newest fashion language (I alone think of C ++ 14? - nn) is not as important as the new fashionable processor technology.
What is important to know about processors, that they are the basis for BP. Since we have limited system resources, we need to understand what we really have at our disposal. A new and elegant language, such as Go, can be incredibly powerful, but it is possible that it will not work in our system with limited resources. (By the way, I was quite amazed how compact the C ++ constructs are, at least under the IAR for the ARM architecture. Nothing superfluous and the entire class syntax and everything else just evaporates in the final code. So even with Go, everything may not be so bad - nn).
After all, you need to know a little bit about everything and everything about something. Expanding existing knowledge is important, but equally important is learning new things that will make you an expert in related fields.
7. Do not be afraid of free software.
There are thousands of software packages that customers want to integrate into their systems, so BP engineers should feel comfortable in this area.
I also want to emphasize that you should avoid closures in one area, because skills almost inevitably become obsolete and impede professional growth. And make sure you understand both the hardware and the software equally; such engineers are highly appreciated.
8. Develop a system of engineering thinking.
It is critical for BP to be systemically oriented. I saw a number of projects that were badly affected by the fact that there were no clearly defined baseline requirements, development strategies, and compliance checks in the early design stages. And every engineer must acquire good project management skills, in case you are asked to make a commitment on time. Having the opportunity to reasonably explain technical and project risks will serve you as a good help in your career.
9. Develop communication skills (both in words and in graphics).
Engineers of all types must be able to effectively express their thoughts and ideas, and often the best way to do this is in a graphical way. Too often, I asked junior engineers to explain the concept of the device and watched them wander around the bush, unable to focus on what they were trying to explain. (By the way, do not forget about the effect of a rubber duckling - nn).
We are used to using flowcharts to explain concepts. Maybe they are somewhat outdated today, but every engineer should have the ability to use flowcharts, state machine diagrams as a basic skill, as well as any other tool that can help in the transfer of concepts. Especially if they try to explain how something works.
Can you imagine a task for a developer who writes software for a controller that explains how the machine that the controller should operate using a text document works? (I can, I have seen such tasks, and even worked on them - nn).
Mindmapping is one of my favorite methods of capturing and visualizing my ideas and thoughts, and I use the iThoughts, MindMapping app for iPad almost every day. (And I do not even know what it is - nn).
10. Master the wireless connection.
The only thing I would recommend to the VZ engineers to master in the next 1-3 years is wireless communication, in particular, Wi-Fi and / or BLE.
The main (and sometimes the only) way to interact with embedded devices goes to the user's smartphones, at least in the field of consumer electronics. Household appliance companies understand that a smartphone is much better adapted to the user than the tools of most embedded systems by themselves. And other industries and manufacturers of end products tend to think about this. (Of course, if you have a final budget, otherwise you can afford your communication devices - nn).
Our embedded systems will need to interact with the application on a smartphone or internet services based on them in order to do something — communicate with the user, get a firmware update, fix a problem, etc.
It may be a bit early to say that WiFi and BLE will soon be as common as UART today (UART yesterday, today USB, but this is a personal opinion expressed in a private conversation - nn), but the trend is obvious and in any case it is enough A good tool to have in your bag of tools.
From the translator:
One should not write in the comments that these 10 points do not contain anything new (I could not resist in one place, but did not delete) - in the end, all mathematics is a tautology. In the end, all the recommendations come from people with rich experience who occupy a certain place in the BP industry, and only therefore deserve attention.
But if someone writes in the comments about what else the BP engineer needs and was, in his opinion, undeservedly bypassed in the article, then this will surely earn the gratitude of the readers and the advantages to karma.
Source: https://habr.com/ru/post/250293/
All Articles