Can you become a firmware engineer(embedded software engineer) through bootcamp?
Hey everyone
I'm trying to find a bootcamp for software developer and i stubbled on to firmware engineer. I got very interested in that topic. I heard that firmware need to know both software and hardware so I was wondering can you still be able to become a firmware engineer without a college degree but by going through a boot camp. If Yes does any one have some good boot camps that they can say postive thing about. Thank you every one!
29 comments
Former embedded engineer here :) Most embedded engineers I know have a degree in Electrical Engineering or Computer Engineering (similar but not exactly the same as Computer Science). The reason is because as an embedded engineer you need to have a good understanding of the electronics and hardware around the microcontroller/microprocessor. For basic applications such as arduino you can get away with high level code, but in order to do more advanced things like motor control, wireless radio, battery management, analog filtering, etc, you need to be familiar with the underlying electronics.
That said, as embedded processors like the raspberry pi get cheaper I am seeing more jobs in embedded Linux, which may require less direct electronics experience.
I would say an electrical engineering degree is the best way, or maybe just read the entire "Art of Electronics" and try to do some personal projects like a robot! There are no easy shortcuts I'm afraid.
I absolutely love doing embedded work, but unfortunately it was hard to find good remote jobs! If you are in a tech city there are many more opportunities. Good luck!
That said, as embedded processors like the raspberry pi get cheaper I am seeing more jobs in embedded Linux, which may require less direct electronics experience.
I would say an electrical engineering degree is the best way, or maybe just read the entire "Art of Electronics" and try to do some personal projects like a robot! There are no easy shortcuts I'm afraid.
I absolutely love doing embedded work, but unfortunately it was hard to find good remote jobs! If you are in a tech city there are many more opportunities. Good luck!
While I can’t 100% say no, I’ve never seen one and I don’t imagine the field being a good fit for the bootcamp process. Nor do I view it as generally friendly to any sort of non traditional developer (including the swath of self taught ones)
Nearly all jobs I’ve seen related to firmware dev have been senior level, requiring many years of experience particularly in the domain the company operates in. I imagine there’s also a significant amount of knowledge that’s behind an NDA or is just not accessible to anyone outside the field. My hunch is that new talent is mostly obtained through university sourcing, but I could be wrong.
Of course, I’m not the one to tell you to just give up and settle, but if I were you I’d try to find a slightly less broad target and make a plan to hit it. If you fail, you fail and likely have achieved swaths of useless knowledge though.
Nearly all jobs I’ve seen related to firmware dev have been senior level, requiring many years of experience particularly in the domain the company operates in. I imagine there’s also a significant amount of knowledge that’s behind an NDA or is just not accessible to anyone outside the field. My hunch is that new talent is mostly obtained through university sourcing, but I could be wrong.
Of course, I’m not the one to tell you to just give up and settle, but if I were you I’d try to find a slightly less broad target and make a plan to hit it. If you fail, you fail and likely have achieved swaths of useless knowledge though.
Nope. But you should check out Embedded Artistry[1], its the single best resource I've seen on a field that's mysterious even to most professional programmers.
Have you spent any time doing Arduino projects? While not representative of real-world firmware work, Arduino is very accessible/cheap and will teach your transferable skills (e.g. C programming for interfacing with HW). I'd encourage you to really put some time in before you commit to anything embedded - because the amount of jobs and the range of companies you can work at is much, much lower than "mainstream" development (say, building web applications).
[1] https://embeddedartistry.com/beginners/
Have you spent any time doing Arduino projects? While not representative of real-world firmware work, Arduino is very accessible/cheap and will teach your transferable skills (e.g. C programming for interfacing with HW). I'd encourage you to really put some time in before you commit to anything embedded - because the amount of jobs and the range of companies you can work at is much, much lower than "mainstream" development (say, building web applications).
[1] https://embeddedartistry.com/beginners/
I don't think the subject is impenetrable, but that doesn't mean you'll find a job. Like web dev, the challenge is tieing together a range of related skills. For example:
Figure out a project you'd like to do. Make it happen using the dev board. Ie buy input and output devices, perhaps on breakout boards. Once you're comfortable with this, learn PCB design software; there are some OK free ones like KiCad. Design and order some custom boards. Learn to solder parts their assembly service doesn't have, or won't install.
As an aside to proficiency, there's something rewarding about making a program that has no noticeable latency due to lack of conflicting priorities, and bloat associated with web and GPOS programming.
- Proficiency in a low-level language (C, C++ or Rust)
- Part choosing
- PCB design
- Knowing how to read datasheets and reference manuals
- Understanding how registers work
- Coding without an allocator
- Balancing performance with power-saving (battery-powered devices etc)
- Control flow patterns unfamiliar to desktop work (Interrupts etc)
- Knowing the capabilities and quirks of the specific hardware you're using
- Setting up a toolchain etc
- API design for turning register-level code into something practical (like writing drivers or a HAL)
- Soldering
Figure out a project you'd like to do. Make it happen using the dev board. Ie buy input and output devices, perhaps on breakout boards. Once you're comfortable with this, learn PCB design software; there are some OK free ones like KiCad. Design and order some custom boards. Learn to solder parts their assembly service doesn't have, or won't install.
As an aside to proficiency, there's something rewarding about making a program that has no noticeable latency due to lack of conflicting priorities, and bloat associated with web and GPOS programming.
In regards to finding a project to start practicing, coupled with buying a dev board, I can recommend this course https://www.edx.org/course/embedded-systems-shape-the-world-...
I did it some time ago, the board they use is pretty cheap and it could be a good starting point. Disclaimer: - I did this course (or similar, but same professors and same university) online some years ago, so I assume it has been updated. - I do not get any benefits, monetary or otherwise, for promoting this course or for new enrollments. I just recommend it based on my personal experience.
I did it some time ago, the board they use is pretty cheap and it could be a good starting point. Disclaimer: - I did this course (or similar, but same professors and same university) online some years ago, so I assume it has been updated. - I do not get any benefits, monetary or otherwise, for promoting this course or for new enrollments. I just recommend it based on my personal experience.
Hi pracer this looks good. Just curious are oscilloscopes and logic analyzers some software or we need to purchase both? (wouldn't be a bad idea to put down the $$ TBH if one wants to take hardware as a serious hobby)
> Debug using oscilloscopes, logic analyzers, and software instrumentation
> Debug using oscilloscopes, logic analyzers, and software instrumentation
Oscilloscopes are hardware that can be used to analyze digital and analog signals. They may be able to interface with a PC (USB) using software as well. logic analyzers are small, usually cheap pieces of hardware that can analyze digital signals only, and rely on software on a connected PC. IMO even the $10 analyzers are great for digital (troubleshooting I2C, SPI etc), and can analyze many channels at once. You only need a scope for analog.
If I could only afford one, I would recommend the o-scope. Most firmware runs on bespoke hardware and the programmer can’t assume the hardware is abstracted away from the software. MANY bugs I’ve tracked down required electronics probing.
Thanks, yeah I know what they are but not sure whether we need to purchase real ones or the course has some simulations.
We have logic analyzers for just 10 bucks? Wow that's much more affordable than I thought. I thought both need like hundreds of bucks.
We have logic analyzers for just 10 bucks? Wow that's much more affordable than I thought. I thought both need like hundreds of bucks.
Pretty unlikely, firmware development is programming for controlling a machine, that can be a industrial machine, toy, a car, a car ECU (Engine Control Unit), a drone or parts of an aircraft. Embedded systems involves bare metal C or C++ programming, RTOS (Real Time Operating Systems), embedded Linux, assembly, electronics, micro-controllers, application processors, DSPs - Digital Signal Processors, ARM core, SOC peripherals (ADC, SPI, I2C, PWM ...), control systems, Matlab Simulink toolboxes. Most companies that deals with embedded systems are not startups or tech companies, they are manufacturing companies from several fields, such as home appliances, radio equipment or car makers. That is the reason why we rarely hear about embedded systems. Most embedded developers are electronic engineers degree holders, even in the CppCon C++ conference, most speakers about embedded systems are electronic engineers.
Theoretically, a self-taught dev could get into it, if they were truly motivated and found the right opportunity, but there's not going to be a boot camp for it, at least in the West. Boot camps exist primarily because the demand for web developers outpaces the supply substantially. The same cannot be said for firmware engineers in the US.
That being said, there are accelerated CS undergrad degrees out there that may help you break into the field in the fewest number of calendar months. Though at the end, there's a good chance you wind up doing web dev anyway.
That being said, there are accelerated CS undergrad degrees out there that may help you break into the field in the fewest number of calendar months. Though at the end, there's a good chance you wind up doing web dev anyway.
No. Not to gatekeep, but I don't think a bootcamp could prepare anyone enough for that. Sorry.
Just to expand on this a little, firmware development is hard even for experienced engineers. My experience is with bluetooth firmware but from what I have seen the problems are pretty typical.
For starters, the tools are generally terrible compared to things like Jetbrains or vscode. Each chip vendor has a preferred environment (i.e. Segger for Nordic stuff) or you have to buy something expensive like IAR and they all have quirks. The Ti toolset for bluetooth stuff is a nightmare.
Next, you need to be an excellent C programmer and it helps to have some experience with assembler. You will need that for debugging. If you struggle with pointers or memory addressing or anything like that you will suffer.
Next, you need a good understanding of concepts like interrupts, how data is stored i.e how memory is used for different data. Plus each RTOS is different so while strategies for how you do things are similar, the available tools can be unique to the vendor.
On top of that, you will likely have to work with the hardware engineers on how the chip is set up, which pins are attached to what, how they are attached and other concepts like SPI and other means of getting data in and out.
There is a lot to learn, you need to learn by doing and hopefully with an experienced mentor available. There is nothing like stack overflow to help either, the chip vendors run their own forums and try to help but largely on a custom board you are on your own.
So, no bootcamp could even come close.
For starters, the tools are generally terrible compared to things like Jetbrains or vscode. Each chip vendor has a preferred environment (i.e. Segger for Nordic stuff) or you have to buy something expensive like IAR and they all have quirks. The Ti toolset for bluetooth stuff is a nightmare.
Next, you need to be an excellent C programmer and it helps to have some experience with assembler. You will need that for debugging. If you struggle with pointers or memory addressing or anything like that you will suffer.
Next, you need a good understanding of concepts like interrupts, how data is stored i.e how memory is used for different data. Plus each RTOS is different so while strategies for how you do things are similar, the available tools can be unique to the vendor.
On top of that, you will likely have to work with the hardware engineers on how the chip is set up, which pins are attached to what, how they are attached and other concepts like SPI and other means of getting data in and out.
There is a lot to learn, you need to learn by doing and hopefully with an experienced mentor available. There is nothing like stack overflow to help either, the chip vendors run their own forums and try to help but largely on a custom board you are on your own.
So, no bootcamp could even come close.
why is this so much harder than making large web apps?
Making a web app is a massive exercise in handholding, where you are 400 layers away from the metal amd barely give a passing thought to how much memory is getting used. Include a whole new javascript library for a bit of screen candy? Why not.
Embedded system, you increased something from a two byte unsigned int to four bytes? Does it still fit on the device ordo I need to change the area in memory where my program is being loaded, do I still have enough space for the stack, was I disciplined about my mallocs and frees and always make the right size etc. Beginners can make a fair fist of a web app because you can screw up royally and it will still work.
Embedded system, you increased something from a two byte unsigned int to four bytes? Does it still fit on the device ordo I need to change the area in memory where my program is being loaded, do I still have enough space for the stack, was I disciplined about my mallocs and frees and always make the right size etc. Beginners can make a fair fist of a web app because you can screw up royally and it will still work.
There's more to know beyond the software aspect. Web apps require a lot of knowledge too, but it mostly falls under the umbrella of software. Application software is just one of many things an embedded engineer does.
Start with the basic skills you'd need for any software like data structures and algorithms. But you'll actually need to know it for the job, not just for the interview.
Add extra low-level computer systems skills.
Add electronics skills.
Depending on the application, you might also need to know control systems, signal processing, communications theory, hardware security, or computer architecture, for example.
Then add the engineering math/physics knowledge for the specific domain.
It adds up. If you can't do those things, all of those problems need to already be solved, simplified, and polished for you. At that point, you've avoided firmware engineering and gone right back to application development.
Start with the basic skills you'd need for any software like data structures and algorithms. But you'll actually need to know it for the job, not just for the interview.
Add extra low-level computer systems skills.
Add electronics skills.
Depending on the application, you might also need to know control systems, signal processing, communications theory, hardware security, or computer architecture, for example.
Then add the engineering math/physics knowledge for the specific domain.
It adds up. If you can't do those things, all of those problems need to already be solved, simplified, and polished for you. At that point, you've avoided firmware engineering and gone right back to application development.
Well one reason is that there's a huge amount of learning resources for web dev because so many people do it. The tools are also really mature and easy to use due to a lot of investment from the community.
Firmware dev you end up working on obscure proprietary systems where you don't have the luxury of just Googling every problem because there isn't a ton of devs working on the same thing as you.
Firmware dev you end up working on obscure proprietary systems where you don't have the luxury of just Googling every problem because there isn't a ton of devs working on the same thing as you.
The electronics labs at university have $10,000s of equipment for use in electronics engineering courses. And you need instructors with experience with both hardware and software. In my experience those with the required level of expertise earn far more in industry than what TAs are typically paid.
Of course you could always have an Arduino based course. But for anything non-trivial you will quickly need some electronic test equipment and the skills to use them well. You only need to browse the Arduino forums to realise how hard it is to learn all the inter-related material.
Any organisation providing a bootcamp style course would need to invest in considerable amount of test equipment, provide lab bench space and hire suitably qualified instructors.
Having said that, there are lots of videos on YoutTube that explain various topics. You might want to read me reply to @runawaybottle for an idea of some of the topics you might need to become familiar with.
Of course you could always have an Arduino based course. But for anything non-trivial you will quickly need some electronic test equipment and the skills to use them well. You only need to browse the Arduino forums to realise how hard it is to learn all the inter-related material.
Any organisation providing a bootcamp style course would need to invest in considerable amount of test equipment, provide lab bench space and hire suitably qualified instructors.
Having said that, there are lots of videos on YoutTube that explain various topics. You might want to read me reply to @runawaybottle for an idea of some of the topics you might need to become familiar with.
If you have already some experience as software developer, I think the most effective way is to get a job as junior embedded software engineer and learn directly on the field. I started my career path in embedded SW in this way and I'm convinced that there is nothing better than learn from more experienced colleagues and practice directly on a real project. This is true in every field, but even more in this difficult area where you need to have good knowledge of both hardware and software. When I started I had almost no experience about hardware, but I could learn a lot from more experienced colleagues that were. Of course the learning curve is slow at the beginning, but it will get faster after 1 year.
I highly doubt there's any kind of bootcamp for it. I got a paid summer internship doing industrial embedded engineering through my university.
There are no shortcuts.
There are no shortcuts.
What makes firmware programming particularly harder?
Firmware isn't necessarily more difficult than other areas, every domain has serious challenges. But firmware programming has the kind of challenges that require a very deep technical background, something almost impossible to build in an X-week boot camp:
- Insane debugging: you have to debug extremely low-level failures with very limited visibility (e.g. no operating system to catch your segfaults) and proprietary or complex tools.
- A hard language made harder: C is difficult to get right, but embedded C (no dynamic memory, lots of bitwise operations for MMIO register writes, targeting exotic architectures, etc) is even more difficult.
- Extreme constraints: The products you work can have constraints like safety certification, minimal power utilization, or ultra low latency response. Meeting those constrains often means having to deeply understand hardware.
- Insane debugging: you have to debug extremely low-level failures with very limited visibility (e.g. no operating system to catch your segfaults) and proprietary or complex tools.
- A hard language made harder: C is difficult to get right, but embedded C (no dynamic memory, lots of bitwise operations for MMIO register writes, targeting exotic architectures, etc) is even more difficult.
- Extreme constraints: The products you work can have constraints like safety certification, minimal power utilization, or ultra low latency response. Meeting those constrains often means having to deeply understand hardware.
The interaction between the software and hardware. This is a huge topic, but I'll try to give an extremely brief summary.
You have a tiny computer with some built-in interfaces. These days it almost always is a SOC and the documentation is often 300-500 pages.
Then you typically have some additional chips connected. Simple ones might have a 10 page doc, complex ones 100+ pages.
And you have your bespoke designed circuitry.
All of these things communicate over a variety of circuits, which generally are susceptible to electrical noise and transmission line effects. At typical frequencies everything over a couple of inches is a transmission line.
Then there are design errors, especially during prototyping.
So when you have a "bug" you need to track down whether the problem (and it can be one or more of the following) is in your code, the interfaces, the wiring, in your understanding of the documentation and of course the documents have errors as well.
Then to further add to your woes, your code edit, compile, download to flash can take several seconds for each iteration. And the flash wears out after say 10,000 iterations.
You have a tiny computer with some built-in interfaces. These days it almost always is a SOC and the documentation is often 300-500 pages.
Then you typically have some additional chips connected. Simple ones might have a 10 page doc, complex ones 100+ pages.
And you have your bespoke designed circuitry.
All of these things communicate over a variety of circuits, which generally are susceptible to electrical noise and transmission line effects. At typical frequencies everything over a couple of inches is a transmission line.
Then there are design errors, especially during prototyping.
So when you have a "bug" you need to track down whether the problem (and it can be one or more of the following) is in your code, the interfaces, the wiring, in your understanding of the documentation and of course the documents have errors as well.
Then to further add to your woes, your code edit, compile, download to flash can take several seconds for each iteration. And the flash wears out after say 10,000 iterations.
You need to know what the computer is doing, down to the chip level. This often includes things like how actual protocols are working on a hardware (electrical) level, and how different parts of the board are connected to each other.
It's sort of like writing Linux drivers for custom hardware, but without the Linux libraries, or Linux.
It's sort of like writing Linux drivers for custom hardware, but without the Linux libraries, or Linux.
[deleted]
[deleted]
I've done a fair amount of embedded programming. (I was the most experienced C programmer at various places and was asked to help out with hardware projects, including Space Shuttle payloads, tools for a new chip design and Vegas slot games.)
What I have noticed is that job postings for dedicated embedded/firmware programmers paid about half what I was already making, so I never put that on my resume.
So I think you're misguided: nobody's going to give you a job as a junior embedded engineer (since they would have to supervise you and debug your code, or face a failed $$$$ hw project), and even if they did, you'd earn half what a CRUD developer can make.
But if you're going down that road, learn the linux tool chain, including how linux boots.
You can find the IBM DOS era BIOS listing manual on ebay.
What I have noticed is that job postings for dedicated embedded/firmware programmers paid about half what I was already making, so I never put that on my resume.
So I think you're misguided: nobody's going to give you a job as a junior embedded engineer (since they would have to supervise you and debug your code, or face a failed $$$$ hw project), and even if they did, you'd earn half what a CRUD developer can make.
But if you're going down that road, learn the linux tool chain, including how linux boots.
You can find the IBM DOS era BIOS listing manual on ebay.
I'm really curious why embedded pays so much lower than CRUD web dev.
My guess is that CRUD product companies have much lower marginal cost of production (just server costs) than hardware so they can afford to pay more.
My guess is that CRUD product companies have much lower marginal cost of production (just server costs) than hardware so they can afford to pay more.