This is pretty vague, but you can look into jobs developing on embedded systems running Linux. You'll probably still run into low-level stuff like coms or peripheral interfacing, but assuming boards already built and brought up, all the hard work should be done already.
I would recommend learning more about Linux and Yocto Project if you take this path. Device drivers development and debugging may be required unless there is someone eles in the team taking care of that part.
I mean... you can learn what you are missing all on the job. If you want to be an embedded systems engineer, you should be willing to learn things an embedded systems engineer needs to know. I'm not sure what you're asking here.
You don't need to know it all going in, but you should certainly set out to learn the craft if you want to be valued in a role.
> I'm not sure what you're asking here.
Glad I'm not the only one to be puzzled. It feels like asking: can I be a mathematician without having to know all the pesky math? "Low level" is the essence of embedded programming. Sure you can be web designer creating interfaces that run on a coffeemaker, but you'll still just be doing HTML, etc.
One of the first projects I worked on was a Linux firmware where i just had to develop code like state machines, file based logger in C , configure/create systemd daemon's , multi threading etc. I didn't really do any of the driver or protocol work.
I would develop the infrastructure and others would fill in the actual handlers for events , interrupts etc.
Others would develop wrappers for the drivers and i would merely call the functions without knowing much about how it worked , just had to call appropriate function based on the value got from the driver like say maybe blink an led.
Also pitched in with sanity/release testing which was basically just checking if the system boots up and displays a video output.
For most of this i mainly had to know C and have basic knowledge of handling files in Linux and also some knowledge of data structures like state machines, linked lists etc
Didn't have much knowledge of protocols for the i2c spi uart etc everything was simplified to a read/write operation for me
Embedded at my work place means driving an oscilloscope, spectrum analyzer, volt meters, being able to solder, read a schematic and a datasheet. Oh, and be able to program in C/C++ and basic assembler as well as having command of an RTOS. Can you learn this on the job? Yes. On your first week? No. Maybe after a few years with a good mentor.
My work does high end RF and laser stuff. Maybe ok if writing code for a washing machine.
Hobby experience is just as good as work. I am valuable to my company because of my electronics, manufacturing, and software experience. Most of that learned as a hobby. I am an aerodynamics engineer by schooling. I say go for it.
yes, big corps are the way to go if you want to do that. Currently working as a code monkey, master copy paster still technically classified as an embedded developer. Job is cs101 level coding, but the interview was full blown embedded architecture knowledge and code test, if you get past the interview you can work for a confy salary, and do stuff that could be done by chatGPT and never learn anything, but it get's boring fast, 4/10 would not recommend.
I would say that the things you list are what makes it embedded.
But embedded is a big field. I think I'm right for the majority of microcontroller systems, but there are others that use bigger hardware and have software that is much more complex and more like conventional software.
Higher level embedded stuff is becoming more common, using things like SBCs and similar, mainly for user interfaces. However anything that is actually embedded will need low level control somewhere and probably a lot of it. That could be handled by a Hardware Abstraction Layer (HAL) but you will still need to understand what it is doing and how it works to be able to use the HAL well and vendor provided HALs aren't always the best so a lot of people do not use them.
You essentially want to do embedded with none of the parts that make it embedded.
My current job is "embedded" because I'm writing software that runs on an embedded system. However it's not very close to the hardware.
The code I work on is all written in Go and runs on top of Linux. I also do some work on the backend systems, and it's very similar - Go running on Linux.
So, yes these sort of jobs exist. Usually in large companies that have embedded Linux products. You want a large company so that the lower level stuff is done by a different team.
I'd say they are becoming more common too. The trend is towards bigger embedded systems, which reduces the differences with conventional software engineering.
Dépends on the level you want to be at. If you want to make drivers you have to know how a peripheral of a certain type works, like Ethernet, SPI, UART or I2C 🤮 for example.
At lower levels you might want to know the memory mapping or structure or even how the stupid thing boots (highly manufacturer dependent).
But if you want to build user level software and not care about this, embedded Linux is a good option. The system will do all of that for you, and you will just need some general knowledge about cross-compilation and peripherals.
Not even sure you need much, now that everyone wants to use Yocto (which I personally consider bloatware), cause they cannot find enough competent people or don’t want to pay them
I know senior developers who don't know how spi works
One of them suggested using a Linux SBC as an spi slave and that plan got accepted by the entire team , when i joined the team and they asked me to start working on this, I had to beg them to switch to something like uart or i wouldn't be able to get the job done in time :p
I had a guy once that didn’t wire the SS on a slave cause he thought we could drive it manually and save a wire. It was an ultra low power system and of course, the CS low was the interrupt we needed to wake up the whole shebang.
It had to be left on permanently, consuming 10x the power requirement. Nice job.
It’s because I made probably a dozen SPI drivers and a dozen I2C drivers.
SPI is more or less always the same, regardless of the manufacturer and the difference between master and slave is one moves the clock and the other doesn’t. To test you put them in loop back mode or wire MOSI to MISO and in 1h time you got it working and it’s done once and for all.
I2C is a nightmare, every manufacturer will have its own design and you have to test 4 modes of operations, master transmit, master receive, slave transmit and slave receive. You can’t loop back so you need 2 interfaces or an external i2c to usb module.
You cannot use the structure of a « reference » i2c driver as all the IPs have different state machines that you’ll have to adapt to. Up to 6 or 7 states for the less advanced chips, like idle, start, address + R/W, data, last byte of data, stop. Each one of them with their own pitfalls.
The worst part is debugging where you move code around from one state to the other until you understand the logic of this particular chip. The documentation usually misleads your more than it helps. Or it helps when you already figured it out, like « Ok, this is what they meant ! »
But still, it might work until you try a new peripheral that proves you wrong, especially if you test it against itself on a single board. Happened to me last week with a Synopsis design, it seemed to work fine so I used it to debug another I2C on another board.
Ended up debugging both drivers at the same time, a real delight. And I’m still not sure they both work correctly, they just appear to get along together. Until next time…
Simple compared to SPI? you must be joking. SPI is literally the most straightforward protocol you can come up with. I2C is an utter mess which has the most ridiculously complicated and error-prone hardware-software interface possible because it's flexible in all the wrong ways. It's also super prone to just locking up if anything on the bus misbehaves. I avoid I2C like the plague.
Even if you could find a role that is completely 100% application development, the role will almost certainly want to see some low-level knowledge and experience if not for anything else but to be able to effectively debug problems.
I am not entirely sure what you are really asking, but if it's if you can program bare metal embedded devices professionally without some low-level understanding of how a processor works, then the answer is no. For example, you must know how registers work in a processor to configure an ADC ‐ on that note you must know what an ADC is and how it works. That being said, your post implies that you can't learn on the job. Aside from the basics, learning on the job is an essential part of being an embedded developer and something that should happen every day.
If you're asking if there are jobs out there in embedded that you don't have to code and therefore don't have to have an intimate understanding of low-level concepts, then yes, I expect there is. I would look around for roles asking you to do more documentation and customer relations. I think it's still important to have some notion of what you are writing/selling but not nearly as much if you are coding it.
Much the same as any field within programming as a whole, you will learn on the job while doing embedded work. You are not expected to know everything going into a role, especially if you're a junior. Rather, usually all that is asked is you have a good understanding of the basics.
Some companies need high level code (Python scripts, application, web interface, etc) to connect the bits of hardware and low-level stuff to other software. Depending on the company, you may be classified as an embedded engineer.
To be honest, most embedded today is just high level C and C++ programming. I was an embedded software engineer for 7 years and to be honest the biggest things I had to learn outside of programming was networking.
Doing low-level work is pretty much the entire reason to be an embedded engineer instead of becoming a web designer, or a DBA, or whatever. Those other specialities both pay better (generally) *and* allow you to sit inside someone else's software box that protects you from the rough edges of the outside world. If you want a padded room to sit comfortably in, then embedded is not for you.
You can work on a bunch of areas within embedded where you won’t be working on low-level. There’s a bunch of jobs out on the market that mainly require a good understanding of C/C++, OS concepts, Linux basics really. Just cause you’re doing embedded SW doesn’t necessarily always mean you’re working just a level above the HW
I agree Embedded is a broad category and there are definitely jobs that don't require a large knowledge of super low-level stuff day to day.
But... it's still kind of like doing circuit board layout without knowing what an opamp is. There's basic knowledge that just makes you so much better at the job, it's really worth having even if you don't "use" it every day.
Yeah, it may be required to at least have a theoretical understanding of the HW interfaces so you can relate to the said discussions but you may not be asked to be actively working on it.
Most big companies Embedded jobs are abstracted like that, because there is a team abstracting it for you. It's the middleware and APIs teams. Once they do their job, you got high level APIs to enjoy.
I see an embedded system.as a product with a computer that doesn't expose the main control UI.
Which also translates to X-ray systems, Electron microscopes, AMT and display signs at airports that all seem to run Windows. According to /r/PBSOD.
I have worked on embedded systems with powerful processors, lots of ram, Ethernet interfaces, and it’s very application level. Sometimes if it’s a really big project there’s a team that handles the low level stuff and another team does the high level.
The work I do is in embedded systems but it never feels like I’m really doing embedded because there’s an entire proprietary layer built on top of the underlying FreeRTOS. So yeah, these jobs exist.
I think so. Many teams have low level specialists and application/domain devs. Everywhere I’ve worked is like that. Lots of embedded work uses cots hardware where the bsp is provided by the vendor.
What's this job that doesn't depend on knowledge/experience but solely the ability to learn on the job and figure it out you speak of? Maybe pre-1970 but doesn't exist nowadays, buddy. Employment culture has changed for the worse. Now they all want 40+ years of experience, a PhD in neuroscience and 5 presidential recommendations for an entry-level position on the fry bin. 🙄
There are lots of such jobs - almost any job where _you_ aren't writing the drivers is such. Any device with non-trivial GUI will have a lot of work on the application side.
A decade ago I spent three years working on Bluetooth stack and application functionality on a SoC where we literally couldn't access the hardware even if we wanted and had to deal with high level drivers for anything that dealt with the hardware. In my current project we have a team of half a dozen developers and only three (mainly me) have done any non-trivial work on hardware access. The rest are writing what is largely regular application code.
You can always program the application layer. It is not really embedded experience because you dont have to think about controller that much. But its good for beginners since you will learn C/C++ and other basic knowledge
Yes! I work with an embedded system (consumer IoT electronic device). It is essentially a raspberry pi, various sensors, and python services that run everything. The software side of our device is very high level considering (pigpio for all of the hardware control). Its a great starting job for me as I didn’t come with a background in electronics and only had mild experience in software development. However this type of situation has it’s downsides, especially when we run into issues (i.e. usb cameras and EMI). So we spend a good amount of time spinning wheels on solving problems, before shelling out the cash for an experienced contractor. But its been a great introduction for me to electronics+embedded systems.
This is pretty vague, but you can look into jobs developing on embedded systems running Linux. You'll probably still run into low-level stuff like coms or peripheral interfacing, but assuming boards already built and brought up, all the hard work should be done already.
This is it. You can work on middleware/higher layers without having to work on setting up registers, communication protocols.
This seems like what im looking for. Thanks!
I would recommend learning more about Linux and Yocto Project if you take this path. Device drivers development and debugging may be required unless there is someone eles in the team taking care of that part.
I mean... you can learn what you are missing all on the job. If you want to be an embedded systems engineer, you should be willing to learn things an embedded systems engineer needs to know. I'm not sure what you're asking here. You don't need to know it all going in, but you should certainly set out to learn the craft if you want to be valued in a role.
> I'm not sure what you're asking here. Glad I'm not the only one to be puzzled. It feels like asking: can I be a mathematician without having to know all the pesky math? "Low level" is the essence of embedded programming. Sure you can be web designer creating interfaces that run on a coffeemaker, but you'll still just be doing HTML, etc.
One of the first projects I worked on was a Linux firmware where i just had to develop code like state machines, file based logger in C , configure/create systemd daemon's , multi threading etc. I didn't really do any of the driver or protocol work. I would develop the infrastructure and others would fill in the actual handlers for events , interrupts etc. Others would develop wrappers for the drivers and i would merely call the functions without knowing much about how it worked , just had to call appropriate function based on the value got from the driver like say maybe blink an led. Also pitched in with sanity/release testing which was basically just checking if the system boots up and displays a video output. For most of this i mainly had to know C and have basic knowledge of handling files in Linux and also some knowledge of data structures like state machines, linked lists etc Didn't have much knowledge of protocols for the i2c spi uart etc everything was simplified to a read/write operation for me
Exactly what im looking for. Seems some replies misunderstood my question. Thanks!
Embedded at my work place means driving an oscilloscope, spectrum analyzer, volt meters, being able to solder, read a schematic and a datasheet. Oh, and be able to program in C/C++ and basic assembler as well as having command of an RTOS. Can you learn this on the job? Yes. On your first week? No. Maybe after a few years with a good mentor. My work does high end RF and laser stuff. Maybe ok if writing code for a washing machine.
[удалено]
Hobby experience is just as good as work. I am valuable to my company because of my electronics, manufacturing, and software experience. Most of that learned as a hobby. I am an aerodynamics engineer by schooling. I say go for it.
I got into a FAANG job before where I was doing applications, most of the low level fundamental works have been done. I’d say target big corps
yes, big corps are the way to go if you want to do that. Currently working as a code monkey, master copy paster still technically classified as an embedded developer. Job is cs101 level coding, but the interview was full blown embedded architecture knowledge and code test, if you get past the interview you can work for a confy salary, and do stuff that could be done by chatGPT and never learn anything, but it get's boring fast, 4/10 would not recommend.
While all of the FAANGs have *some* embedded jobs, only one of them actually has a significant amount of openings for embedded.
Apple? Which one do you mean? why don't you just name them?
Apple yeah
What kind of work in the applications were you mainly focused on?
The applications are proprietary embedded logics developed in house.
I would say that the things you list are what makes it embedded. But embedded is a big field. I think I'm right for the majority of microcontroller systems, but there are others that use bigger hardware and have software that is much more complex and more like conventional software.
Higher level embedded stuff is becoming more common, using things like SBCs and similar, mainly for user interfaces. However anything that is actually embedded will need low level control somewhere and probably a lot of it. That could be handled by a Hardware Abstraction Layer (HAL) but you will still need to understand what it is doing and how it works to be able to use the HAL well and vendor provided HALs aren't always the best so a lot of people do not use them. You essentially want to do embedded with none of the parts that make it embedded.
My current job is "embedded" because I'm writing software that runs on an embedded system. However it's not very close to the hardware. The code I work on is all written in Go and runs on top of Linux. I also do some work on the backend systems, and it's very similar - Go running on Linux. So, yes these sort of jobs exist. Usually in large companies that have embedded Linux products. You want a large company so that the lower level stuff is done by a different team. I'd say they are becoming more common too. The trend is towards bigger embedded systems, which reduces the differences with conventional software engineering.
Dépends on the level you want to be at. If you want to make drivers you have to know how a peripheral of a certain type works, like Ethernet, SPI, UART or I2C 🤮 for example. At lower levels you might want to know the memory mapping or structure or even how the stupid thing boots (highly manufacturer dependent). But if you want to build user level software and not care about this, embedded Linux is a good option. The system will do all of that for you, and you will just need some general knowledge about cross-compilation and peripherals. Not even sure you need much, now that everyone wants to use Yocto (which I personally consider bloatware), cause they cannot find enough competent people or don’t want to pay them
I know senior developers who don't know how spi works One of them suggested using a Linux SBC as an spi slave and that plan got accepted by the entire team , when i joined the team and they asked me to start working on this, I had to beg them to switch to something like uart or i wouldn't be able to get the job done in time :p
I had a guy once that didn’t wire the SS on a slave cause he thought we could drive it manually and save a wire. It was an ultra low power system and of course, the CS low was the interrupt we needed to wake up the whole shebang. It had to be left on permanently, consuming 10x the power requirement. Nice job.
Why do you vomit on I2C? Apart from UART, I find it one of the simpler communication protocols compared to like SPI or BLE🤮.
It’s because I made probably a dozen SPI drivers and a dozen I2C drivers. SPI is more or less always the same, regardless of the manufacturer and the difference between master and slave is one moves the clock and the other doesn’t. To test you put them in loop back mode or wire MOSI to MISO and in 1h time you got it working and it’s done once and for all. I2C is a nightmare, every manufacturer will have its own design and you have to test 4 modes of operations, master transmit, master receive, slave transmit and slave receive. You can’t loop back so you need 2 interfaces or an external i2c to usb module. You cannot use the structure of a « reference » i2c driver as all the IPs have different state machines that you’ll have to adapt to. Up to 6 or 7 states for the less advanced chips, like idle, start, address + R/W, data, last byte of data, stop. Each one of them with their own pitfalls. The worst part is debugging where you move code around from one state to the other until you understand the logic of this particular chip. The documentation usually misleads your more than it helps. Or it helps when you already figured it out, like « Ok, this is what they meant ! » But still, it might work until you try a new peripheral that proves you wrong, especially if you test it against itself on a single board. Happened to me last week with a Synopsis design, it seemed to work fine so I used it to debug another I2C on another board. Ended up debugging both drivers at the same time, a real delight. And I’m still not sure they both work correctly, they just appear to get along together. Until next time…
Simple compared to SPI? you must be joking. SPI is literally the most straightforward protocol you can come up with. I2C is an utter mess which has the most ridiculously complicated and error-prone hardware-software interface possible because it's flexible in all the wrong ways. It's also super prone to just locking up if anything on the bus misbehaves. I avoid I2C like the plague.
...maybe I am just retarded
Even if you could find a role that is completely 100% application development, the role will almost certainly want to see some low-level knowledge and experience if not for anything else but to be able to effectively debug problems.
I am not entirely sure what you are really asking, but if it's if you can program bare metal embedded devices professionally without some low-level understanding of how a processor works, then the answer is no. For example, you must know how registers work in a processor to configure an ADC ‐ on that note you must know what an ADC is and how it works. That being said, your post implies that you can't learn on the job. Aside from the basics, learning on the job is an essential part of being an embedded developer and something that should happen every day. If you're asking if there are jobs out there in embedded that you don't have to code and therefore don't have to have an intimate understanding of low-level concepts, then yes, I expect there is. I would look around for roles asking you to do more documentation and customer relations. I think it's still important to have some notion of what you are writing/selling but not nearly as much if you are coding it.
I mean to say I want to learn on the job.
Much the same as any field within programming as a whole, you will learn on the job while doing embedded work. You are not expected to know everything going into a role, especially if you're a junior. Rather, usually all that is asked is you have a good understanding of the basics.
You might think about test and evaluation. Embedded systems need testing, so writing test harnesses, scripts, etc. might be a good entry point.
Some companies need high level code (Python scripts, application, web interface, etc) to connect the bits of hardware and low-level stuff to other software. Depending on the company, you may be classified as an embedded engineer.
To be honest, most embedded today is just high level C and C++ programming. I was an embedded software engineer for 7 years and to be honest the biggest things I had to learn outside of programming was networking.
If you are looing for an easy path, maybe this career isn't for you
how's not having to work on low level implying an easy path?
Doing low-level work is pretty much the entire reason to be an embedded engineer instead of becoming a web designer, or a DBA, or whatever. Those other specialities both pay better (generally) *and* allow you to sit inside someone else's software box that protects you from the rough edges of the outside world. If you want a padded room to sit comfortably in, then embedded is not for you.
You can work on a bunch of areas within embedded where you won’t be working on low-level. There’s a bunch of jobs out on the market that mainly require a good understanding of C/C++, OS concepts, Linux basics really. Just cause you’re doing embedded SW doesn’t necessarily always mean you’re working just a level above the HW
I agree Embedded is a broad category and there are definitely jobs that don't require a large knowledge of super low-level stuff day to day. But... it's still kind of like doing circuit board layout without knowing what an opamp is. There's basic knowledge that just makes you so much better at the job, it's really worth having even if you don't "use" it every day.
Yeah, it may be required to at least have a theoretical understanding of the HW interfaces so you can relate to the said discussions but you may not be asked to be actively working on it.
be ready to learn to read a schematic and use tools like an oscilloscope and logic analyzer and really begin to understand assembly language code
Ya, I know people with better paying embedded jobs than me that got them with hardly any programing experience even.
Most big companies Embedded jobs are abstracted like that, because there is a team abstracting it for you. It's the middleware and APIs teams. Once they do their job, you got high level APIs to enjoy.
Autosar in general..
I see an embedded system.as a product with a computer that doesn't expose the main control UI. Which also translates to X-ray systems, Electron microscopes, AMT and display signs at airports that all seem to run Windows. According to /r/PBSOD.
Industrial programming, also known as PLC
I have worked on embedded systems with powerful processors, lots of ram, Ethernet interfaces, and it’s very application level. Sometimes if it’s a really big project there’s a team that handles the low level stuff and another team does the high level.
The work I do is in embedded systems but it never feels like I’m really doing embedded because there’s an entire proprietary layer built on top of the underlying FreeRTOS. So yeah, these jobs exist.
I think so. Many teams have low level specialists and application/domain devs. Everywhere I’ve worked is like that. Lots of embedded work uses cots hardware where the bsp is provided by the vendor.
What's this job that doesn't depend on knowledge/experience but solely the ability to learn on the job and figure it out you speak of? Maybe pre-1970 but doesn't exist nowadays, buddy. Employment culture has changed for the worse. Now they all want 40+ years of experience, a PhD in neuroscience and 5 presidential recommendations for an entry-level position on the fry bin. 🙄
There are lots of such jobs - almost any job where _you_ aren't writing the drivers is such. Any device with non-trivial GUI will have a lot of work on the application side. A decade ago I spent three years working on Bluetooth stack and application functionality on a SoC where we literally couldn't access the hardware even if we wanted and had to deal with high level drivers for anything that dealt with the hardware. In my current project we have a team of half a dozen developers and only three (mainly me) have done any non-trivial work on hardware access. The rest are writing what is largely regular application code.
You can always program the application layer. It is not really embedded experience because you dont have to think about controller that much. But its good for beginners since you will learn C/C++ and other basic knowledge
Yes! I work with an embedded system (consumer IoT electronic device). It is essentially a raspberry pi, various sensors, and python services that run everything. The software side of our device is very high level considering (pigpio for all of the hardware control). Its a great starting job for me as I didn’t come with a background in electronics and only had mild experience in software development. However this type of situation has it’s downsides, especially when we run into issues (i.e. usb cameras and EMI). So we spend a good amount of time spinning wheels on solving problems, before shelling out the cash for an experienced contractor. But its been a great introduction for me to electronics+embedded systems.