10 skills needed today by the developer of embedded systems (free translation with comments)

    Industry experts urge developers of embedded systems (VR) to leave the comfort zone and acquire new skills so as not to lose relevance in the profession.

    If we look at the situation in 1980, the guy (mainly the guys who deal with the controllers) who developed the mixed signal processing scheme, the guy who connected the MK, the guy who wrote assembly code, and the guy who carried the prototype out ( probably, I mean debugging — a note of a translator), I was one and the same person (I myself am one of those, although, of course, it started in the USSR much later than 1980 -pp). All this was done to a large extent by one engineer.

    As the embedded systems got bigger 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 complete BIOS source code was supplied with the IBM PC), the time came for dividing into hardware development, development firmware and software development within one device.

    Many large companies still do. But it seems that the pendulum has swung back, as in more and more large companies role consolidation sets in and developers who are fluent in both hardware and software and are trying to do more with less are in fashion. Accordingly, an increasing 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 didn’t disappear anywhere, just for some time there was an opinion in the industry that the principle of decomposition and specialization is a silver bullet and allows good results to be achieved by a team of mediocrity - nn).

    Since we do not want to lag behind progress in the field of BP, how to determine which skills that we can acquire or develop are the most relevant today?

    EE Times magazine turned to 9 professionals in BP (apparently, they had a failure in the address book, nothing else that they did not contact me, I can’t explain - pp) and recruiters and asked them to tell them what they think about the most important things a modern engineer in the field of BP needs.

    Although opinions on the importance of specific skills were divided (I would be surprised if they were NOT divided -pp), all respondents agreed on one thing: an engineer should never stop learning. (The following are recommendations from various engineers with a work experience in BP of the order of tens of years - an individual experience of each, not all ten at once, -pp).

    1. Learn technologies that are related to the use of the Internet.
    If you know how to do a mixed signal processing scheme and write code in C or C ++, then you already know a lot of useful things in BP, but just writing code in C is not enough in many cases. (This is probably a call to study libraries - pp).

    Using technologies that make it possible to connect your devices to the Internet is a big plus for an engineering career. In fact, I am currently working on several initiatives that include implementing “virtual” XML in BP. (I also made such systems and was amazed at the simplicity and ease of implementing such things on the basis of standard software modules, but if you also understand what is happening ... - pp). We use this technology to provide offline processing of meta-data transactions from very different devices connected using standard low-level protocols and proprietary protocols to influence the network level of abstraction. (I can’t say that I understood this phrase to the end, maybe readers are more lucky - pp).

    I guess it should be something like P&P technology for small network devices. (By the way, in the Edison model from Intel a significant step has been taken in this direction - pp).

    2. You have a search engine, use it.
    Do not waste your time inventing the wheel, use open source. I suspect that someone has already written almost any piece of code that you could only dream of. (I’m not sure that everything, but a lot has really been written, though a lot of software has a fatal drawback - pp).

    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 over the Internet.

    Do not sit in your nook trying to solve puzzles through experimentation. You must become a member of the community. Help people when you can, and they are likely to do the same. (It is unlikely that these will be the same people - pp). Open source is an amazingly powerful tool that only works if people work together.

    3. Learn something new outside your comfort zone.
    Although following the latest trends can be useful and almost always fun, the biggest benefits are achieved by deepening or expanding the field of knowledge. Accept the challenge to find out something outside your comfort zone, such as hardware, your company's domain experience, or project management. (Probably, the respondent has a different meaning in the term project management - pp).

    Focus on improving your basic skills and your inherent advantages, but do not forget to work on interacting with people around you, better understanding their motives (Thank you, captain - pp). Engineering is fundamentally human activity, and the key is to maintain a balance of interests. Too many young engineers focus too much on either human interaction or design. I know this is not easy, but you can really do more good by working on developing both skill sets.

    4. Make friends with the RTOS.
    Engineers who have mastered the formal structural development processes when using RTOS are in great demand and claim high salaries, due to the fact that they realized the need for some rigor in designing critically safe products and deeply accepted the ideas of concurrency. Given that the CPU can launch another task at any time, they know how to protect shared resources while maintaining performance. (I looked at a lot of code for RTOS and far from all of it corresponds to the last phrase. Nevertheless, 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 using - pp).
    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 - pp). I am also starting to see the possibility of using embedded Linux systems in the developed devices, since Linux (in general) 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 greater optimization and functionality.

    5. Diversify your skills and move up the stack.
    If you are still working with bare code or small microcontrollers, I advise you to work with Linux drivers, which will make it easier for you to switch to Android later. (I did not quite understand why I would need Android, but as they say, do not renounce the prison and the sum - pp). And, although this is perhaps less significant, if you are used to working in large systems, try working with bare code.

    Moving up the stack: make a mobile application or master the back end server. This will give you new knowledge and awareness of perspectives.

    And check out 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 many finished boards (probably referring to development kits - pp) that allow me to focus on the unique part of development.

    Of course, this may make me think that all my past firmware developments have become unnecessary and working with boards has not been as fun as before, but we should accept changes to the rules of the game. Unfortunately, this simultaneously means that I meet fewer and fewer people with specific skills (apparently I mean the ability to develop from scratch - pp), and those who are are literally dying out.

    6. Know the familiar software perfectly, but do not forget about the new compilers.
    It’s not bad at all to know several languages ​​(I hope programming languages, otherwise I should leave the profession - np), 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 should learn languages ​​based on their specific needs, embedded engineers should look wider. A deep understanding of C or C ++ is critical, but knowledge of the latest fashion language (am I the only one thinking about C ++ 14? - pp) is not as important as the new fashionable processor technology.

    What is important to know about processors is that they are the basis for BP. Since we have limited system resources, we must understand what we really have at our disposal. A new and sleek language, such as Go, can be incredibly powerful, but it is possible that it will not work on our system with limited resources. (By the way, I was very amazed at how compact designs C ++ generates, at least under the IAR for ARM architecture. Nothing more and the whole class syntax and everything else just evaporates in the final code. So with Go, everything can be not so bad - pp).

    In the end, you should know a little about everything and everything about something. Expanding existing knowledge is important, but equally important is learning new things, which 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 locking in one area, as skills almost inevitably become obsolete and interfere with professional growth. And make sure you understand both hardware and software; such engineers are much appreciated.

    8. Develop a system of engineering thinking.
    It is critically important for BP to be system-oriented. I saw a number of projects that were hit hard by the fact that there were no clearly defined basic requirements, development strategies, and compliance checks in the early stages of design. And each engineer must acquire good project management skills, in case you are asked to make a commitment on time. Having the opportunity to reasonably explain the technical and design risks will serve you well in your career.

    9. Develop communication skills (both in words and in graphics).
    Engineers of all types should 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 the junior engineers to explain the concept of the device and watched them wander around the bush, unable to concentrate on what they were trying to explain. (By the way, do not forget about the effect of the rubber duckling - pp).

    We are used to using flow charts to explain concepts. Maybe they are a little outdated today, but each engineer should have the ability to use block diagrams, diagrams of state machines, as well as any other tool that can help in conveying concepts as a basic skill. Especially if they are trying to explain how something works.

    Can you imagine a task for a developer who writes software for a controller that explains how the machine works, which the controller should control using a text document? (I can, I saw such tasks, and even worked on them - pp).

    Mindmapping is one of my favorite methods of capturing and visualizing my ideas and thoughts, and I use the iThoughts, MindMapping iPad app almost every day. (And I don’t even know what it is - pp).

    10. Get started with wireless.
    The only thing I would recommend to 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 of interacting with embedded devices goes to the user's smartphones, at least in the field of consumer electronics. Household appliance companies realize that a smartphone is much better suited to the user than most embedded systems on their own. And other industries and manufacturers of end products are inclined to this idea. (Of course, if you have a finite budget, otherwise you can afford your communication devices - pp).

    Our embedded systems will need to interact with an application on a smartphone or Internet services based on them in order to do something - to communicate with the user, receive a firmware update, fix the problem, etc.

    Maybe it’s too early to say that WiFi and BLE will soon be as widespread as UART today (UART yesterday, today USB, but this is a personal opinion expressed in a private conversation - pp), but the trend is obvious and in any case it’s enough A good tool to have in your tool bag.

    From a translator:
    You should not write in the comments that these 10 points do not contain anything new (I myself 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, occupying a certain place in the BP industry, and this is why they deserve attention.

    But if someone in the comments writes about what the VR engineer still needs and, in his opinion, was undeservedly ignored in the article, then this will surely earn readers' gratitude and pluses in karma.

    Only registered users can participate in the survey. Please come in.

    How would you react to the offer to take an additional professional training course

    • 5.2% Why is it for me, smart to teach - only to spoil 11
    • 58% Why not, if you don’t have to pay for it 122
    • 50% Why not if the employer pays for it 105
    • 37.1% I am so interested that I am willing to pay myself 78

    Also popular now: