Are there specialties in embedded areas

I began to learn the built-in and two main languages ​​(c and C ++). But I'm starting to understand that, despite the simple requirements for learning, the built-in is the whole world in itself. And once you engage in realistic projects, you begin to realize that you need to learn more of the “things” that are specific to the hardware used in the device you are working on. This is a problem that was rarely thought up only for software projects that I am currently working on.

Is it possible to fragment this field in subfields? I think that those who have experience in this field may have noticed that some types of projects are different from other types, which led them to the fact that maybe they can come up with their own categories. For example, when you come across a project, you might think that it is “off the field”? Is this happening to you? and if so, what would you call your subfield or other subfields you encountered?

+6
c ++ c embedded
source share
6 answers

Here are a few sub-specialties that I can think of:

Subscriber Assembly Specialist

  • Yes. You need to know C and C ++. But some people also specialize in assembly. These are experts who are called upon to transfer RTOS to a new chip or compress every drop of performance from a very limited embedded system (usually to save $$ per unit).
    This person is probably not needed these days, but ... but still critical from time to time.

Device Driver Specialist

  • Convenient living between real OS or RTOS and hardware. This person is usually comfortable with laboratory tools such as o-scopes or logic analyzers, thinking in "hex" and understanding the critical nature of synchronization with HW. This person reads the data sheets of the device for entertainment at night and is very worried about creating the perfect porting driver for some new device.

DSP Specialist

  • Digital signal processing is apparently its own sub-specialty of the built-in ones, although perhaps the software developer may not know the exact details of the algorithm and can only do what the system or electrical engineer requires. However, understanding the theory of sampling rate, FFT, and some of the basic elements from DSP is convenient and perhaps necessary. And you, as a rule, should be very aware of the timing and limitations of your target equipment (sample rate, noise, bit per sample, etc.).

Management Theory Specialist

  • Perhaps the same problem as in the DSP: a system or an electrical engineer can provide detailed specifications. But, again, getting to know the various motors, sensors and other controllers controlled by the microcontroller would be wonderful. Throw Bode into the plot, some Laplace transforms or two and some higher mathematical skills ... that could not really hurt!

Network specialist

  • basically the same as the "world" for the PC. Currently, many embedded devices add network connectivity features. TCP / IP sockets, http, etc., Good to know and understand how to use a device with limited resources. For a correct assessment, enter USB and Bluetooth.

User interface specialist

  • more and more built-in devices include 2D graphics, and now more includes 3D graphics thanks to the influence of the iPhone, etc. Although they are still bold systems by other standards for embedded devices, they are still limited. Just read a little in the Android Development Guide and you'll realize that you still need to consider responsiveness, performance, etc. Even in a high-end mobile phone. http://developer.android.com/guide/practices/design/performance.html

And then, of course, each industry is a specialization for itself. Consumer electronics, military, avionics, robotics, industrial machines, medical devices, etc.

Good luck and good luck!

+12
source share

Yes, of course, there are several subfields. I don’t think I can list them all from my head, but as I see it, there are at least 3 large divisions, and from there they are even more subdivided. There are microcontrollers, microprocessors, and sandboxes / virtual machines. For example, using a 16-bit microcontroller in a drive by wire will be an example of the first, a set-top box such as TiVo will be an example of the second, and iPhone and Androids will be the last.

Microcontrollers are very limited and usually cannot be programmed in C ++. Most of them either do not work on the OS, or, most expensive, have an RTOS. Installation boxes and any ARM / MIPS / SuperH4 / Broadcom chips are much more similar to PCs, because they have a Linux distribution and you can find most of the same tools as a PC, t find one, cross-compiling to it is usually simple. Sandbox guys, fine, with sand; so this is exactly what utilities usually SDK isolates you from the hardware, and you really do not get a "full built-in experience."

+6
source share

Of course, there are many operating systems used in the embedded world. Working with embedded Linux is very different from working with a clean microcontroller.

+3
source share

"Learning the built-in" sounds is impossible for me. I am doing some work on headless linux computers that control large machines that can be called embedded (but this is not much different from programming on any other computer using several hardware interfaces). It is completely different from a telephone and completely different from an air conditioning system or home automation.

Control systems and mobile devices will be two categories of “embedded”, but I am sure that there are many more.

+2
source share

I am working on embedded Linux on mobile devices, and its entire lot is different from the full flegded image of Ubuntu, where I write my code and cross-compile it for a mobile device.

First of all, the embedded system is trimmed to suit the user's requirements, unlike the traditional desktop operating system, where you can have so many features / libraries, etc.

Memory limits are also an important part of an embedded system. Therefore, all programs / applications must be written in order to fit into the architecture. This one may not be very dangerous for a traditional system.

Basically, I want to emphasize that work on embedded ones cannot be summed up in several lines, since each of them has a different purpose.

However, programming with a common architecture can help you gain confidence if you can fit into the project or not.

PS: Perhaps I am not very good at what exactly this question expects, but this is my bit on embedded systems.

+2
source share

Many good answers already to this question. I think you need to decide what the word firmware means for you and / or what you want it to mean. Perhaps your definition is really not inline. My definition means the lack of an operating system. And that would probably upset many software engineers, but experienced ones like the ones who already answered would probably understand our variations in the definition and why. I think they will call me a microcontroller specialist, and this is certainly true, but I spend most of my time on full-speed processors with memory and rom and I / O, network, etc. I am the guy who brings hardware for the first time, washes the board and chip errors, and then passes it on to what most would call software engineers. I am an electrical engineer by profession and a software engineer by profession, so I saddled the line.

It is very possible, and not uncommon, that you can stay in the built-in C / C ++ world, never have to read a technical description or diagram, all you have to do is call the api that someone else created. There is a large and increasingly large market for this, like what used to be (my definition) true built-in, or built-in rtos (which is often apy calls, and not a complete experience) for this linux-built thing that exploded. There is nothing wrong with that, it’s pretty close to the experience of developing code for the desktop, but you need to try a little harder for reliable code, since it may be based on flash / rom and they may not want to have weekly / monthly units updated in the field . Ideally, never update, but it is also becoming increasingly rare.

The embedded linux api is based on rtos / embedded and can still be different than what I call application programming. You can still or want to read the table or diagram, you still need to know the assembler for the target platform.

I like all the answers so far to this question, I think we are struggling to understand what you really ask or what you really look for in life, add to what we like in our choice and you will get this combination of answers .

I see several groups, of course, there is a good old real built-in microcontroller, but even this turns into libraries and apis, and not metal, look at the arduino and stellaris community and a bunch of others. I spend a lot of time training and testing on board, you should know a fair amount of all the system hardware, registers, circuits, etc. You need to know enough assembler both to load things from reset, and how to debug things, looking at dismantling dumps and look for signs of life in I / O buses or memory buses, etc. If you are lucky, you will also start working on the design of the chips and get the opportunity to monitor the implementation of your instructions in the simulation. The next group is the bootloader / operating system. The hardware is working pretty well at the moment, the chip boots, the memory seems to be working, the rom is. This command writes the production boot code and gets the product from inclusion in the embedded system, rtos, linux, vxworks, bsd, whatever. it is talent in itself, a toolchain, a root file system, etc. The next group is the masses, software developers who write applications for this operating system, now some will read data tables, diagrams, etc., writing device drivers or apis for other users, and at the highest level there may be someone whoever programs at the application level, calls api and sdk, some of which can be developed by the company, some of which can be acquired or others.

Bottom line: Absolutely, there are built-in functions. Are you going to know everything? NO, perhaps 20 years ago, probably 40 years ago, and not today the field is too large and wide. What are the best things you can do for yourself in this area? Learn assembler for several sets of instructions. The most popular, of course, is the hand, the version of the thumb, maybe mips or powerpc or others. If you are leaning towards microcontrollers, study (hand, thumb) avr, pic (blah), msp430, maybe 8051. Read some data sheets, microcontrollers can teach you, even if this is not the field you want, tons of development for $ 50 / eval boards (e.g. sparkfun.com) that provide fact sheets, simple schemas, assembler, C, etc. If you are a software developer, learn to speak hardware guys, people with software and hardware do not speak the same language, if you can avoid the choice of parties and remain neutral and speak both languages ​​so that you help yourself, your career and with whom whatever you work. Despite any personal views you may have regarding entants or bit or byte numbering, you will probably have to deal with some comic things and talk with clients / colleagues who can only deal with octal (yes, really) or deal only with msbit something equal to zero. I recommend looking at verilog and possibly vhdl. At least in a readable sense, it is not necessary to create it from scratch. If you can already program and know C, this is very readable. Depending on the work and colleagues, Verilog and the schema may be your only documentation that you use to write your software. If you cannot do this, they can replace you with someone who can (rather than force hardware people to document their materials).

+2
source share

All Articles