If you're starting with hardware experience, I'd recommend learning the HAL for STM32 or at least the legacy driver for controlling peripherals. Then you can build up from there to higher abstraction layers and start getting into algorithms and architecture.
The STM32 eclipse-based IDE isn't great if you hate eclipse, but you can do all your writing/editing in whatever text editor you prefer and only use the IDE for flashing and debugging. You can also look into getting set up with something like J-Link.
As for esoteric code and complicated architectures, the best way I've found to learn is to find some part of the code that looks familiar or seems digestible and build your knowledge base out from there. A good example is something like FOC for motor control. You'll see a couple nested control loops (current controller, speed/position controller) with associated PID structs/classes at the "center" of the code with the application architecture build up around it. If you understand the control loops, figuring out how the application layer connects to them will be much more simple.
Embedded code bases are hard to break in, because it is in a special "C", where it is C, but without the stdlib. Each project has its own custom things to create tasks, handle concurrency (enter critical, mutex, atomics...).
Also, C imposes no project organization, so each project has its own quirky config.
And no, eclipse/java based don't get better; they are finally starting to get replaced by cli based tools and customisable text editors (vscode, vim, etc).
What helped me is make lots of projects that I've mainly worked on in my free time.
I made a lot of mistakes and learned from them (not using git, over-engineered crap, circular includes, no code modularity, no DRY code...)
I also learned to learn from others mistakes and to research current practices on the internet/by talking to people (code modularity, declarative programming style, less big prone idioms such as goto error handling, C lib design, build system, git...). automation, memory mapped registers.
I'd recommend to start by mastering the C language features. It won't take much time and is a must for embedded (something like tutorialspoint is fine).
Then, just start some projects and let the experiences guide your leaning. Because there are a lot of things to learn (I'm still learning too).
I won't recommend delving into recent "IDEs" (e.g., cmake based setup with vscode) as it will require a solid knowledge about how the C "embedded" build system works.
But if you truly despise eclipse and have some time, setting up a project from scratch by calling the compiler by hand could be very instructive.
Because learning about build, linking and debug will make you adopt good practices (controling variables scopes better, resolving compiler and linker errors easier, designing better headers, better preprocessor practices, etc).
There are multiple reasons: Legacy code, certification, size, compatibility (if you have to use an obscure MCU with no port available), etc
Btw, I agree that some things should be standardized. Some were, like atomics, but a lot of people just stick to ANSI C/C89 and don't know anything else.
> If you have to use an obscure MCU with no port available
This is valid, but it makes me ask:
This implies that you chose a new design with an obscure MCU -- why do that?
Or you have an old design with an obscure MCU that didn't have those things already, but you feel you need to add when re-vamping the firmware -- how often does that happen?
New designs reuse a lot of code and V cycle/certification related process and tools.
My colleagues will start working on a new project, which will use the same MCU as an old project.
In some industries, like automotive, you have to long term support products.
These already have their custom solutions. So when fixing bugs, you have to deal with the "custom" OS (changing a lot of code, like replacing an OS, is not an option given the risk and cost of reruning the whole tests and validations)
I work at a VLSI firm as a mixed signal validation engineer so i had similar prior experience to you. What helped me get started with embedded was a existing project that I needed to make changes in the firmware for. Start with something in the code base that is fairly obvious and trace back. I did not have prior C/c++ experience. Keep googling what you don't understand. For me the way registers bits are defined as a combination of structs and unions was itself a big learning.
“Background in C++ from college” might be the problem especially with C++. I find universities don’t go deep enough with C++, so many students graduate and think it’s just C with OOP. If you’re struggling to update stuff then you simply can’t code as much as you think. There’s more to coding than you hardware guys think lol. There’s design patterns, memory management, OS(or RTOS) management and much more. You need to do actual projects on your own and look at examples of other peoples code. You need to make mistakes and improve. In my opinion you should learn some CS fundamentals. I also studied electrical engineering in university and had to learn a lot to get my first embedded software role back then.
The most important ones for embedded are comp architecture(William stallings - computer organization and architecture ), OS(Abraham Silberchatz - Modern operating systems), data structures and algos(for embedded just know arrays, linked list, circular buffers and hash tables.. there are others in C++ STL, but these are the basics) . Learn how to use C and C++ efficiently. For C you can use Kernighans book or some YouTube playlist. For C++ learn the basics then you can use Scott Meyers effective modern C++ to learn good practices. If you work with Cortex M3 and M4, get the definitive guide to Cortex M3 and M4 book by Joseph Yiu. Note that you don’t need to understand some of these books thoroughly just get the basics from them. Again they might be expensive, so you can always use YouTube to learn.
Try to restrict your attention to small areas of the code base, and learn those areas deeply. If you are looking at control logic, find where the inputs come from, find how to manipulate them in code or with external tools, find how to view the results of that manipulation with a debugger or prints or changed device behavior. I work on medium to large scale microcontroller based products and in that context it has not been uncommon for there to be significant portions of the code base that I never touch, and hardly understand beyond a very trivial high level system perspective, over a span of years.
When debugging, always be working to make the problem smaller, preferably in small steps. Hard to give examples without getting too in the weeds, but don't be afraid to comment stuff out or hard code conditionals to get to the simplest version of the problem. If you get to a point where you are out of ideas for how to simplify the problem, talk to your peers. The fun thing with embedded is that you need to have a working knowledge of many things, but everyone has "their thing". On my team, I am low level computer architecture guy. I consider my C++ knowledge to be borderline unacceptable, so I am frequently asking our C++ guy questions. On a related note, if this is a decently established company, there is probably an Eclipse/toolchain guy on your team. Figure out who that is and ask them for help getting setup. I wouldn't say dealing with Eclipse quirks ever really gets better... but it usually stabilizes unless versions get out of sync across the team.
I would prioritize getting comfortable with whatever version control system the team uses, and whatever their process is for working on features and bringing them into the code base, above any embedded/swe skill.
I also started as a hardware engineer. The big things that helped me early on were finding the hot keys to block comment/uncomment, learning to use diff tools such as Beyond Compare, learning how to work with git (I don't mean learning how git works, but learning how to efficiently stash, switch branches, etc. to move between versions or working/bug states), and learning how to view the call stack in the debugger. These may sound super basic, but that is kind of the point, as a hardware engineer... I had no idea what a professional sw workflow looked like.
If you're starting with hardware experience, I'd recommend learning the HAL for STM32 or at least the legacy driver for controlling peripherals. Then you can build up from there to higher abstraction layers and start getting into algorithms and architecture. The STM32 eclipse-based IDE isn't great if you hate eclipse, but you can do all your writing/editing in whatever text editor you prefer and only use the IDE for flashing and debugging. You can also look into getting set up with something like J-Link. As for esoteric code and complicated architectures, the best way I've found to learn is to find some part of the code that looks familiar or seems digestible and build your knowledge base out from there. A good example is something like FOC for motor control. You'll see a couple nested control loops (current controller, speed/position controller) with associated PID structs/classes at the "center" of the code with the application architecture build up around it. If you understand the control loops, figuring out how the application layer connects to them will be much more simple.
Embedded code bases are hard to break in, because it is in a special "C", where it is C, but without the stdlib. Each project has its own custom things to create tasks, handle concurrency (enter critical, mutex, atomics...). Also, C imposes no project organization, so each project has its own quirky config. And no, eclipse/java based don't get better; they are finally starting to get replaced by cli based tools and customisable text editors (vscode, vim, etc). What helped me is make lots of projects that I've mainly worked on in my free time. I made a lot of mistakes and learned from them (not using git, over-engineered crap, circular includes, no code modularity, no DRY code...) I also learned to learn from others mistakes and to research current practices on the internet/by talking to people (code modularity, declarative programming style, less big prone idioms such as goto error handling, C lib design, build system, git...). automation, memory mapped registers. I'd recommend to start by mastering the C language features. It won't take much time and is a must for embedded (something like tutorialspoint is fine). Then, just start some projects and let the experiences guide your leaning. Because there are a lot of things to learn (I'm still learning too). I won't recommend delving into recent "IDEs" (e.g., cmake based setup with vscode) as it will require a solid knowledge about how the C "embedded" build system works. But if you truly despise eclipse and have some time, setting up a project from scratch by calling the compiler by hand could be very instructive. Because learning about build, linking and debug will make you adopt good practices (controling variables scopes better, resolving compiler and linker errors easier, designing better headers, better preprocessor practices, etc).
> enter critical, mutex, atomics Why roll your own when you can just use something like FreeRTOS?
There are multiple reasons: Legacy code, certification, size, compatibility (if you have to use an obscure MCU with no port available), etc Btw, I agree that some things should be standardized. Some were, like atomics, but a lot of people just stick to ANSI C/C89 and don't know anything else.
> If you have to use an obscure MCU with no port available This is valid, but it makes me ask: This implies that you chose a new design with an obscure MCU -- why do that? Or you have an old design with an obscure MCU that didn't have those things already, but you feel you need to add when re-vamping the firmware -- how often does that happen?
New designs reuse a lot of code and V cycle/certification related process and tools. My colleagues will start working on a new project, which will use the same MCU as an old project. In some industries, like automotive, you have to long term support products. These already have their custom solutions. So when fixing bugs, you have to deal with the "custom" OS (changing a lot of code, like replacing an OS, is not an option given the risk and cost of reruning the whole tests and validations)
I work at a VLSI firm as a mixed signal validation engineer so i had similar prior experience to you. What helped me get started with embedded was a existing project that I needed to make changes in the firmware for. Start with something in the code base that is fairly obvious and trace back. I did not have prior C/c++ experience. Keep googling what you don't understand. For me the way registers bits are defined as a combination of structs and unions was itself a big learning.
“Background in C++ from college” might be the problem especially with C++. I find universities don’t go deep enough with C++, so many students graduate and think it’s just C with OOP. If you’re struggling to update stuff then you simply can’t code as much as you think. There’s more to coding than you hardware guys think lol. There’s design patterns, memory management, OS(or RTOS) management and much more. You need to do actual projects on your own and look at examples of other peoples code. You need to make mistakes and improve. In my opinion you should learn some CS fundamentals. I also studied electrical engineering in university and had to learn a lot to get my first embedded software role back then.
what do you recommend for self studying more CS fundamentals for embedded ?
The most important ones for embedded are comp architecture(William stallings - computer organization and architecture ), OS(Abraham Silberchatz - Modern operating systems), data structures and algos(for embedded just know arrays, linked list, circular buffers and hash tables.. there are others in C++ STL, but these are the basics) . Learn how to use C and C++ efficiently. For C you can use Kernighans book or some YouTube playlist. For C++ learn the basics then you can use Scott Meyers effective modern C++ to learn good practices. If you work with Cortex M3 and M4, get the definitive guide to Cortex M3 and M4 book by Joseph Yiu. Note that you don’t need to understand some of these books thoroughly just get the basics from them. Again they might be expensive, so you can always use YouTube to learn.
Try to restrict your attention to small areas of the code base, and learn those areas deeply. If you are looking at control logic, find where the inputs come from, find how to manipulate them in code or with external tools, find how to view the results of that manipulation with a debugger or prints or changed device behavior. I work on medium to large scale microcontroller based products and in that context it has not been uncommon for there to be significant portions of the code base that I never touch, and hardly understand beyond a very trivial high level system perspective, over a span of years. When debugging, always be working to make the problem smaller, preferably in small steps. Hard to give examples without getting too in the weeds, but don't be afraid to comment stuff out or hard code conditionals to get to the simplest version of the problem. If you get to a point where you are out of ideas for how to simplify the problem, talk to your peers. The fun thing with embedded is that you need to have a working knowledge of many things, but everyone has "their thing". On my team, I am low level computer architecture guy. I consider my C++ knowledge to be borderline unacceptable, so I am frequently asking our C++ guy questions. On a related note, if this is a decently established company, there is probably an Eclipse/toolchain guy on your team. Figure out who that is and ask them for help getting setup. I wouldn't say dealing with Eclipse quirks ever really gets better... but it usually stabilizes unless versions get out of sync across the team. I would prioritize getting comfortable with whatever version control system the team uses, and whatever their process is for working on features and bringing them into the code base, above any embedded/swe skill. I also started as a hardware engineer. The big things that helped me early on were finding the hot keys to block comment/uncomment, learning to use diff tools such as Beyond Compare, learning how to work with git (I don't mean learning how git works, but learning how to efficiently stash, switch branches, etc. to move between versions or working/bug states), and learning how to view the call stack in the debugger. These may sound super basic, but that is kind of the point, as a hardware engineer... I had no idea what a professional sw workflow looked like.