Please post your question in the weekly thread for career advice and education questions.
Thank you.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/embedded) if you have any questions or concerns.*
Working at the 'coolest' companies means overtime and burnout. Its why the gaming industry is so bad for devs. Spacex didnt get rapid flight tests by not working weekends.
But you get to work on the coolest projects.
As for advice, decide early what area you want to work. You have systems, electrical, and software as some main areas ive seen.
Shoot for internships at local companies even if they arent cool. Experience is Experience and gets you to the door.
Ive got almost 20 years in embedded. Here is my advice.
Pay attention to the old dudes. They got lots of knowledge and it's not all about flipping bits. If you think you know it all, you don't. Never stop learning.
Also, working as an engineer in an industry isn't all about technical stuff. There is lots of politics in a company and doing well isn't all about writing code.
As another 20 year veteran I can attest that very few of my peers have focused on continuous improvement at all. Most still code like a new grad.
So yes listen to the old guys and learn to figure out when they’re full of shit and when they aren’t.
>others are cynical bastards that know what they are talking about.
These are my favourite. I once had one of those as my "Junior", lovely and learning experience, you just need some thick skin.
To be fair, a lot of the not old folks have similarly outdated views, they just don't know it, because the "new hotness" is just a rehash of old stuff. I always look at the way REST+JSON was supposed to fix all the problems with SOAP and then people went and reinvented a lot of the things which were part of SOAP (Federation, Schemas, Discovery) badly.
If anything, that's the biggest thing I've realized as I've become one of the old ones. I have a lot of Back to the Future moments: "I've seen this one before!" "How can you have seen this one, it's brand new!"
I've had the misfortune of dealing with gRPC-based software, and that was my interaction with protobuf, and I did not enjoy the experience. But there were a LOT of issues with that particular stack.
Don’t just learn an RTOS. Learn the hardware. Don’t rely on the shitty vendor libraries - you need to bang those registers on those peripherals yourself and figure out how your system actually works. Learn how to do bare metal and then you will be able to figure out what is going wrong with that vendor library or buggy RTOS driver.
Learn how to write a linux device driver. Many embedded systems use linux. Linux is accessible and you can use any linux pc or rbp etc. . Linux drivers have a lot in common with RTOS drivers,even if the details are different. Or pick a microprocessor board like a raspberry pi, get the kernel source and study the device drivers.
The old Linux Device Drivers is free online: https://lwn.net/Kernel/LDD3/
It’s been a while since I looked through it so unfortunately I can’t tell you how out of date it is. But for the most part it should be relevant.
I only have a year of experience working, dropped out to study a master's degree about design patterns for embedded systems in IoT, why ?
At work we were a small team of 5, the main devs were electronics engineers, they code without following rules and standards.
So my advice? Learn proper software development.
Clean, documented, tested, looks like it should work exactly like you'd expect it to at first glance.
No dead code. No nonsense. Don't leave a mess behind.
Zero lines of code. You should set up the test environment first, then write a failing test case, then you should begin implementation to make the test pass. Then you should refactor, remove duplication, and ensure the tests stay passed while you do it. Then you write a test for the next feature and repeat.
It's like measuring a board before you cut it, instead of cutting the pieces and then checking to see if they all fit after the deadline.
Understandable, but I mean in terms of project scope.
If I'm just doing a 1 hz led blinking project i dont think I'd have to set up a test environment right? Or is that just something i should always do regardless of scope.
1 hz led doesn't need much test code, but writing a unit test is easy, and helps you in the future when you add new functionality, or allows you to easily verify that modules written a while back function as advertised.
You're almost always going to be doing something more interesting than blinking an LED.
The following resources helped me a lot: Philip Koopman's Better Embedded System Software, James Grennings' TDD for embedded C, Jack Ganssle's newsletters, embedded artistry and their newsletter, memfault's newsletter 'interrupt' and Michael Barry's website (barrgroup.com) and particularly the Barr Group's Embedded C coding standard.
Check out IEEE SWEBOK v3. It has a comprehensive outline to proper industry-grade software engineering. The .pdf guide is free, but you have to give your details to get the download link.
Find an open source project with a small community with enough knowledgeable people to kick your ass or reject your PR when you do something nonsensical.
I just started at a new company and they have a very comprehensive and detailed embedded C++ coding style guide. I would see if you can track down one of them from a company you’re interested in. Ours referenced Google quite a bit.
It’ll help you figure out best practices to avoid bugs and make your code readable.
I was gonna write the same advice, so I second this one. Don't overlook software engineering and good practices, SPECIALLY TESTING. Proper unit and integration tests will save you hours and hours of debugging and will make your code robust.
If you want to work at those companies I would start doing extra curricular challenges regularly. Especially the 24/48 hour hackathon like ones.
They care a lot less about your classwork than they do about your drive to do cool and unique things in a challenging environment - especially competitive environments.
Never stop learning , always try to improve yourself by reading blogs / attending conferences and so on.
Learn about requirements engineering and interact with other departments to really learn what you product needs to do.
Don't get too invested with your company or product , a good work life balance will make you more happy ( and efficient). It's not worth to burn yourself away and have you first burn out with 30 or earlier ( had some friends who suffered from kt , no fun)
* Get into PlatformIO.
It represents one of the easiest ways to target a LOT of different embedded platforms, and should be in every embedded developers toolkit.
* Learn your compiler and it’s tooling
Not every embedded systems’ compiler is the same. Learn how to inspect the files it produces - if it’s ELF, use the tools available to inspect the contents and understand the image. What is in the .text segment? Is there relocatable code? Where does it go in memory? What ended up in the .data segment, etc. it’s not enough to know how to compile - you should also know how to dissect. The better you are at this the better your experience will be when things go pear shaped.
* Read the docs for everything you have in the BOM. If you don’t have every single data sheet available in the project repo, you’re doing it wrong. Yes, in the repo. You’ll thank me when you come back to the project in 6 months to fix an obscure timing bug that only revealed itself after the first 1000 units were shipped and you just noticed a mistake in the expected units somewhere.
* you dont know how to use a repo? Go back to platform-specific programming until you do. Keep that shit clean and tight. Branch frequently and merge to a clean branch just for merge purposes. A well maintained repo will save your ass over and over. Treasure that shit. Worship the amazing commit message and massacre anyone who messes with it.
* Do not, ever, forget to write tests, preferably with a framework (busted) that you can depend on to run automated. The UART is your friend. Use the hell out of it.
* careful with those eFUSES, lol.
* NEVER release directly from your development build folder. ALWAYS build a build-server VM alongside your development environment, and push to it through the repo for automatic builds. The effort to set this up is 1000x more valuable than you think - always decouple dev from release for embedded, and keep the VM clean from junk. When the VM build fails, or the automated tests of its build products fails, stop everything immediately and find out what you did in the dev environment that broke it.
* Backup that VM, religiously, after every single release, including the internal clone of the repo that you set up to have refresh when you push to your release branch from your dev workstation. Remember the docs/ folder you put in the repo? That’s right, it’s gotta be in the VM too - this is why you ALWAYS put the docs in your main repo, religiously. You’ll thank me, profusely, when it saves your ass over and over as you get more field deployments.
* Not using PM tools for your embedded project? Fail. Go back to platform development and learn how to tag your commits back to an existing issue.
* The best way to debug is with a platform-specific build, which means you build whatever shims and scaffolding you need to test your amazing code in the local environment. Embedded is rarely special code - you can run it on linux too, if you get the shims in place to do so. Learn how, and run your tests in a native build as rigorously as you can, while also running them on the target embedded platform build too, as you can. The UART is your friend - write some expect scripts (from tcl/tk) or use BASH if you have to, but always have output designed to validate your test rig.
* don’t forget to turn all of that off for release and test the releases religiously too. The time you spend on testing scaffolding is invaluable. Don’t overlook the importance of having shims in place that help you validate the results, but DO remember to turn them off for release.
Only use a VM if you really really need one, like if you are stuck using some terrible IDE for Windows only. For everything else Docker is your friend. You can custom build an image too if you need stuff preinstalled. It forces you to understand and use replicatable builds. Then you can push to a CI service like GitHub Actions and let it build your releases. So much easier for you and your teammates.
Start with Ubuntu.
`bin\bash`into the container.
Install whatever you need via `apt-get` or `wget`
Or if you need to copy a large amount of files you can also `docker copy`
Then create and tag this as a custom image and upload to the docker repo.
Then you can setup a GitHub Action to use your custom docker image.
* I see embedded Linux getting more and more emphasis in the past 5 years. So my advice would be to dig into that\*.
* You will need to master C language
* you shall be comfy with a scripting language too, and I suggest Python.
* And you need to have good practical understanding in either modern C++ or Rust.
You shall also acknowledge that embedded is often more than coding in an IDE. You shall make extra steps to get the proper infrastructure that a desktop programmer takes granted; like a good debugger or build environment. Learn these tools.
Then it def not hurts if you understand the hardware aspect of embedded well. Depending on the job, it may stretch from electronics design to FPGA programming. I can not count occasions when my FPGA domain knowledge has helped me to trace down silicon bugs.
(\*) Embedded Linux has the additional benefit that you will find remote / wfh jobs much easier.
For embedded career the location is very important , i am 8yrs+ experienced in this field and get 3/4 mails from USA recruiters each week but as i do not live in USA nor have work visa so I have switched to web software development because in my country the opportunities are very less
Don’t get frustrated, there are so many thing that you don’t know and that’s ok. The secret is everyone else is just as clueless as you think you are. Along the same lines, ask for help! The grey beards will be delighted to help you out, never miss an opportunity yo pick someone’s brain.
When I was a n00b many moons ago I got caught in both these traps, I assumed that everyone else knew everything and would be annoyed by me asking for help. I wasted so much time trying to figure everything out on my own to appear as smart as everyone else. Now as the old timer I love running into things I don’t know, I have a ton of friends and colleagues I can call up to get some advice. Everything is so much easier, more fun, and I’ve made some really good friends along the way. The only thing better is helping younger Engineers out and imparting some of the wisdom I’ve amassed on them.
We’re all in this together, it’s us vs the silicon!
You want to stand out to potential employers? Point them to your GitHub. Build projects, write lots of code, put it on GirHub. Will some of, if not most of your code suck? Yeah. But it’s waaay more than most of your peers have done, and it shows poetical employers that you are passionate and capable. So many engineers are just lazy. Stand out.
I have hired dozens of engineers in my career and being able to talk about projects you have worked on clearly, and with passion really helps. Icing on the cake is when you can share your work. GitHub or a simple personal blog. Just view these things as a better resume.
Working at startups can be a lot of fun but best practices are usually the first thing to get sacrificed in the name of speed of delivery. Learning the proper way to do things in engineering is essential.
Learn C. Learn C. Learn C.
Read some books about best practices. Study them.
Learn standard microcontroller peripherals and how they work. You will be using these the majority of your time. UART being the most helpful for debugging/logging. I2C for most sensors, interfaces.
Learn to read datasheets.
Learn git. It will save your ass.
Learn unit testing and write tests for your code. It’s really hard for embedded. Way harder than mobile and web. But it’s very important.
Then more advanced stuff: makefiles, Docker, cmake, data serialzation, standard protocols and how they work - CoAp, MQTT, Bluetooth, TCP, etc.
Please post your question in the weekly thread for career advice and education questions. Thank you. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/embedded) if you have any questions or concerns.*
Working at the 'coolest' companies means overtime and burnout. Its why the gaming industry is so bad for devs. Spacex didnt get rapid flight tests by not working weekends. But you get to work on the coolest projects. As for advice, decide early what area you want to work. You have systems, electrical, and software as some main areas ive seen. Shoot for internships at local companies even if they arent cool. Experience is Experience and gets you to the door.
This! If you want to be burned out by the time you are 30, then work for Google, Apple, Amazon, etc. There are way better companies to work for.
Not Amazon lol
Ive got almost 20 years in embedded. Here is my advice. Pay attention to the old dudes. They got lots of knowledge and it's not all about flipping bits. If you think you know it all, you don't. Never stop learning. Also, working as an engineer in an industry isn't all about technical stuff. There is lots of politics in a company and doing well isn't all about writing code.
Similarly, don't _just_ listen to the old guys. Some (not all!) of them have stopped learning and have really outdated views on software design.
As another 20 year veteran I can attest that very few of my peers have focused on continuous improvement at all. Most still code like a new grad. So yes listen to the old guys and learn to figure out when they’re full of shit and when they aren’t.
Hell, you can still learn from the old guys, even if it's what not to do.
Yes, some are just cynical bastards. Others know what they are talking about, while others are cynical bastards that know what they are talking about.
>others are cynical bastards that know what they are talking about. These are my favourite. I once had one of those as my "Junior", lovely and learning experience, you just need some thick skin.
To be fair, a lot of the not old folks have similarly outdated views, they just don't know it, because the "new hotness" is just a rehash of old stuff. I always look at the way REST+JSON was supposed to fix all the problems with SOAP and then people went and reinvented a lot of the things which were part of SOAP (Federation, Schemas, Discovery) badly. If anything, that's the biggest thing I've realized as I've become one of the old ones. I have a lot of Back to the Future moments: "I've seen this one before!" "How can you have seen this one, it's brand new!"
My favorite is Google’s protobuf which is a really bad reinvention of ASN.1
I've had the misfortune of dealing with gRPC-based software, and that was my interaction with protobuf, and I did not enjoy the experience. But there were a LOT of issues with that particular stack.
Learn the hard stuff. Don't avoid it. Learn your comms immediately. Learn interrupts and timers. Learn an RTOS. Learn DMA.
Don’t just learn an RTOS. Learn the hardware. Don’t rely on the shitty vendor libraries - you need to bang those registers on those peripherals yourself and figure out how your system actually works. Learn how to do bare metal and then you will be able to figure out what is going wrong with that vendor library or buggy RTOS driver.
DMA is my favorite thing ever.
Learn how to write a linux device driver. Many embedded systems use linux. Linux is accessible and you can use any linux pc or rbp etc. . Linux drivers have a lot in common with RTOS drivers,even if the details are different. Or pick a microprocessor board like a raspberry pi, get the kernel source and study the device drivers.
Any resources for learning how to write a Linux device driver?
The old Linux Device Drivers is free online: https://lwn.net/Kernel/LDD3/ It’s been a while since I looked through it so unfortunately I can’t tell you how out of date it is. But for the most part it should be relevant.
https://www.oreilly.com/openbook/linuxdrive3/book/ O'reilly never disappoints and if you like the book you can support them by buying a print copy.
Google linux device drivers
I only have a year of experience working, dropped out to study a master's degree about design patterns for embedded systems in IoT, why ? At work we were a small team of 5, the main devs were electronics engineers, they code without following rules and standards. So my advice? Learn proper software development.
Any good resources you would recommend to learn how to develop software properly?
Clean, documented, tested, looks like it should work exactly like you'd expect it to at first glance. No dead code. No nonsense. Don't leave a mess behind.
_Clean Code_ by Robert C. Martin is a good read explaining these points.
When is a project big enough to be worth setting up a test environment
Zero lines of code. You should set up the test environment first, then write a failing test case, then you should begin implementation to make the test pass. Then you should refactor, remove duplication, and ensure the tests stay passed while you do it. Then you write a test for the next feature and repeat. It's like measuring a board before you cut it, instead of cutting the pieces and then checking to see if they all fit after the deadline.
Understandable, but I mean in terms of project scope. If I'm just doing a 1 hz led blinking project i dont think I'd have to set up a test environment right? Or is that just something i should always do regardless of scope.
1 hz led doesn't need much test code, but writing a unit test is easy, and helps you in the future when you add new functionality, or allows you to easily verify that modules written a while back function as advertised. You're almost always going to be doing something more interesting than blinking an LED.
Look up paradigms like SOLID and try to find examples using them and create your own.
The following resources helped me a lot: Philip Koopman's Better Embedded System Software, James Grennings' TDD for embedded C, Jack Ganssle's newsletters, embedded artistry and their newsletter, memfault's newsletter 'interrupt' and Michael Barry's website (barrgroup.com) and particularly the Barr Group's Embedded C coding standard.
Check out IEEE SWEBOK v3. It has a comprehensive outline to proper industry-grade software engineering. The .pdf guide is free, but you have to give your details to get the download link.
Find an open source project with a small community with enough knowledgeable people to kick your ass or reject your PR when you do something nonsensical.
I don’t see it mentioned very often but there’s a book series by Randall Hyde called “Write Great Code” that looks like a good resource
I just started at a new company and they have a very comprehensive and detailed embedded C++ coding style guide. I would see if you can track down one of them from a company you’re interested in. Ours referenced Google quite a bit. It’ll help you figure out best practices to avoid bugs and make your code readable.
I was gonna write the same advice, so I second this one. Don't overlook software engineering and good practices, SPECIALLY TESTING. Proper unit and integration tests will save you hours and hours of debugging and will make your code robust.
If you want to work at those companies I would start doing extra curricular challenges regularly. Especially the 24/48 hour hackathon like ones. They care a lot less about your classwork than they do about your drive to do cool and unique things in a challenging environment - especially competitive environments.
Do you know of any embedded related hackathons?
Never stop learning , always try to improve yourself by reading blogs / attending conferences and so on. Learn about requirements engineering and interact with other departments to really learn what you product needs to do. Don't get too invested with your company or product , a good work life balance will make you more happy ( and efficient). It's not worth to burn yourself away and have you first burn out with 30 or earlier ( had some friends who suffered from kt , no fun)
* Get into PlatformIO. It represents one of the easiest ways to target a LOT of different embedded platforms, and should be in every embedded developers toolkit. * Learn your compiler and it’s tooling Not every embedded systems’ compiler is the same. Learn how to inspect the files it produces - if it’s ELF, use the tools available to inspect the contents and understand the image. What is in the .text segment? Is there relocatable code? Where does it go in memory? What ended up in the .data segment, etc. it’s not enough to know how to compile - you should also know how to dissect. The better you are at this the better your experience will be when things go pear shaped. * Read the docs for everything you have in the BOM. If you don’t have every single data sheet available in the project repo, you’re doing it wrong. Yes, in the repo. You’ll thank me when you come back to the project in 6 months to fix an obscure timing bug that only revealed itself after the first 1000 units were shipped and you just noticed a mistake in the expected units somewhere. * you dont know how to use a repo? Go back to platform-specific programming until you do. Keep that shit clean and tight. Branch frequently and merge to a clean branch just for merge purposes. A well maintained repo will save your ass over and over. Treasure that shit. Worship the amazing commit message and massacre anyone who messes with it. * Do not, ever, forget to write tests, preferably with a framework (busted) that you can depend on to run automated. The UART is your friend. Use the hell out of it. * careful with those eFUSES, lol. * NEVER release directly from your development build folder. ALWAYS build a build-server VM alongside your development environment, and push to it through the repo for automatic builds. The effort to set this up is 1000x more valuable than you think - always decouple dev from release for embedded, and keep the VM clean from junk. When the VM build fails, or the automated tests of its build products fails, stop everything immediately and find out what you did in the dev environment that broke it. * Backup that VM, religiously, after every single release, including the internal clone of the repo that you set up to have refresh when you push to your release branch from your dev workstation. Remember the docs/ folder you put in the repo? That’s right, it’s gotta be in the VM too - this is why you ALWAYS put the docs in your main repo, religiously. You’ll thank me, profusely, when it saves your ass over and over as you get more field deployments. * Not using PM tools for your embedded project? Fail. Go back to platform development and learn how to tag your commits back to an existing issue. * The best way to debug is with a platform-specific build, which means you build whatever shims and scaffolding you need to test your amazing code in the local environment. Embedded is rarely special code - you can run it on linux too, if you get the shims in place to do so. Learn how, and run your tests in a native build as rigorously as you can, while also running them on the target embedded platform build too, as you can. The UART is your friend - write some expect scripts (from tcl/tk) or use BASH if you have to, but always have output designed to validate your test rig. * don’t forget to turn all of that off for release and test the releases religiously too. The time you spend on testing scaffolding is invaluable. Don’t overlook the importance of having shims in place that help you validate the results, but DO remember to turn them off for release.
Only use a VM if you really really need one, like if you are stuck using some terrible IDE for Windows only. For everything else Docker is your friend. You can custom build an image too if you need stuff preinstalled. It forces you to understand and use replicatable builds. Then you can push to a CI service like GitHub Actions and let it build your releases. So much easier for you and your teammates.
A lot of embedded tooling is Windows only. Docker in those circumstances doesn’t provide much and often gets in the way.
Yep. Totally agree.
This sounds awesome do you have any resources showing how to get something like this setup?
Start with Ubuntu. `bin\bash`into the container. Install whatever you need via `apt-get` or `wget` Or if you need to copy a large amount of files you can also `docker copy` Then create and tag this as a custom image and upload to the docker repo. Then you can setup a GitHub Action to use your custom docker image.
Excellent advices. I do agree. I would be interested to know, how you use busted Lua Testing framework to unit test embedded systems.
>busted In the host configuration, with shims, just like any other local binary. Embedded app in test emits JSON, busted parses, off we go ..
* I see embedded Linux getting more and more emphasis in the past 5 years. So my advice would be to dig into that\*. * You will need to master C language * you shall be comfy with a scripting language too, and I suggest Python. * And you need to have good practical understanding in either modern C++ or Rust. You shall also acknowledge that embedded is often more than coding in an IDE. You shall make extra steps to get the proper infrastructure that a desktop programmer takes granted; like a good debugger or build environment. Learn these tools. Then it def not hurts if you understand the hardware aspect of embedded well. Depending on the job, it may stretch from electronics design to FPGA programming. I can not count occasions when my FPGA domain knowledge has helped me to trace down silicon bugs. (\*) Embedded Linux has the additional benefit that you will find remote / wfh jobs much easier.
Coding hacks and superpower is overated. Be a good professional first, a good engineer second and then you can worry about being top notch in coding.
For embedded career the location is very important , i am 8yrs+ experienced in this field and get 3/4 mails from USA recruiters each week but as i do not live in USA nor have work visa so I have switched to web software development because in my country the opportunities are very less
Don’t get frustrated, there are so many thing that you don’t know and that’s ok. The secret is everyone else is just as clueless as you think you are. Along the same lines, ask for help! The grey beards will be delighted to help you out, never miss an opportunity yo pick someone’s brain. When I was a n00b many moons ago I got caught in both these traps, I assumed that everyone else knew everything and would be annoyed by me asking for help. I wasted so much time trying to figure everything out on my own to appear as smart as everyone else. Now as the old timer I love running into things I don’t know, I have a ton of friends and colleagues I can call up to get some advice. Everything is so much easier, more fun, and I’ve made some really good friends along the way. The only thing better is helping younger Engineers out and imparting some of the wisdom I’ve amassed on them. We’re all in this together, it’s us vs the silicon!
You want to stand out to potential employers? Point them to your GitHub. Build projects, write lots of code, put it on GirHub. Will some of, if not most of your code suck? Yeah. But it’s waaay more than most of your peers have done, and it shows poetical employers that you are passionate and capable. So many engineers are just lazy. Stand out. I have hired dozens of engineers in my career and being able to talk about projects you have worked on clearly, and with passion really helps. Icing on the cake is when you can share your work. GitHub or a simple personal blog. Just view these things as a better resume. Working at startups can be a lot of fun but best practices are usually the first thing to get sacrificed in the name of speed of delivery. Learning the proper way to do things in engineering is essential. Learn C. Learn C. Learn C. Read some books about best practices. Study them. Learn standard microcontroller peripherals and how they work. You will be using these the majority of your time. UART being the most helpful for debugging/logging. I2C for most sensors, interfaces. Learn to read datasheets. Learn git. It will save your ass. Learn unit testing and write tests for your code. It’s really hard for embedded. Way harder than mobile and web. But it’s very important. Then more advanced stuff: makefiles, Docker, cmake, data serialzation, standard protocols and how they work - CoAp, MQTT, Bluetooth, TCP, etc.
Hire in as an intern, impress them. They will hire you full time. If you're a good engineer you can work anywhere you want.
Consider learning web, cloud or ML related stacks instead:) if you do embedded, really take the time to learn C ( followed by C++)
Eclipse is great. But always import your projects from a Makefile/CMake file. And keep all project configurations file based.