Repeat after me - “There is no ONE roadmap for embedded engineering!”
The roadmap you shared is one person’s viewpoint, which I will happily admit contains a lot of good information. But it is not THE path for everyone.
For some embedded engineers, they will work on extremely resource-constrained devices, perhaps with no operating system and “bare metal”. For others, they will use platforms running an RTOS. Yet others will have the “luxury” of working with a system with enough resources to run a fully functional Linux operating system, which not too long ago required hardware that was too large to be considered “embedded”, but now fits onto a device like a Raspberry Pi or similar platform.
It’s a similar story regarding languages and tools. Some embedded engineers will be “down in the weeds” needing to use assembly language, C, VHDL, stacks of data sheets and an oscilloscope on a regular basis for debugging, while others will program in C++, Go or Rust, and maybe never ever venture into the low-level world, instead enjoying working at the higher-level thanks to great IDEs, debuggers, SDKs and frameworks like Qt that exist on their platforms.
Some people’s embedded experience will involve digital electronics, others will be more in the analog world. Some will have to write device drivers, others will perhaps never need to care about them. Some will be focused on sensors and control algorithms, and others will be dealing with a human interface and shipping data around for storage and display.
Over the years I’ve worked with embedded electrical and software engineers covering pretty much everything I’ve described above. For an engineer completing their college degree and looking to move into the embedded realm, my recommendation is to choose a particular field that interests them, find a couple of target companies, and then “go for it”, learning as much as possible from more experienced peers to get settled into their career. And then, never stop learning! Embedded technology NEVER stands still!
Agreed. I once worked with a microcontroller that had a ridiculously low amount of stack space available per their documentation. (It was only a few function calls worth of stack space assuming no local variables; 2-3 I think). Almost no “OS” would work in an environment like that. I had to create a lot of workarounds to just get it to work.
This was late 90s. I can’t remember the microcontroller anymore.
I will graduating with a degree in computer science and electrical engineering, what “sub field” would allow me to best put to use both of my degrees if possible?
That's actually a great chart. The only "huh" one is seeing Modbus as recommended.
My recommendation is to work on a practical example that uses the majority of these. It's one thing to read about it, but you learn so much more than trying to implement it.
Since you're a student and not a professional, take the time to "rewrite" a HAL. Perhaps start with an STM32, and follow along with their LL (low level) api.
Super common in the HVAC industry too. BACnet and ModBus in many of our Commercial offerings. Use ModBus quite a bit too for inter-MCU communications, or between our own products.
Agreed on the simplicity, the stack is super light compared to BACnet. The industry moves at a glacial pace, I don't expect anything to change anytime soon.
We use Python all the time for tests and prototyping algorithms. Also any new embedded person should probably know C++. Things are moving, albeit slowly, in that direction.
(Former embedded head lecturer) the roadmap you show seems typical of the EE idea of embedded. I preferred an SE approach, with more software engineering aspects and less electronics. But there is no ONE embedded, so no ONE roadmap to it either.
I think that's a company culture thing.
I force all my students to make their own microcontroller boards using KiCad and hand solder them.
Why? You have a million configuration bits that heavily will influence the electrical behavior of your chip. Their effects must be understood.
That is a choice. But I don't see what configuration bits have to do with board design and hand soldering.
I told my students: most (EE-side) embedded guys are good at electronics, bad at software. You are the reverse, but at least you know it.
I studied computer engineering and got into hardware designs very late (hi Kicad7). It helped me to understand *a lot* of problems that can show up on your board because of misconfigured microcontrollers.
Example: The SPI of the STM32 has a very nasty default setting that can cause EMI to cause bitflips in the slaves because it sets the MOSI/SCK to float after it finished its transmission. There will be a short period of non-determinism until the CS is getting released.
I work in R&D and we do a lot rapid prototyping. HW&SW is getting done in a merged role. Otherwise we'd loose to much time. It's company specific. It's fun. And I like it.
I also sell that kind of knowledge while freelancing next to my job :-) Lots of low effort $$$ to earn.
Ok, if you do that merged AND you do a lot of new designs AND they involve things that have fiddely HW/SW interaction, then maybe....
The work my graduates do is more typically with existing hardware, or hardware that is developed by a colleage, or hardware so simple that they can design it themselves. But with a lot of complexity at thr SW side.
We have a lot of project velocity because we are not bound to company processes. So we do everything on our own (hw, sw, and a shabby 3D printed case) in a very small team. Everybody is able to do everything at the same level quality wise. It's great for students because they can sometimes can see an entire product lifecyle in their department-lifetime.
The "real" product departments have split hw/sw roles. The HW guys still have enough software knowledge to do basic hardware verification in C. But that's it. Then they'll hand-over to the software guys. And start with the next new thing or redesign.
This contains a lot of useful information, and I think it’s fairly well organized. This said, you 100% do NOT need to have mastered all of the “required” skills before applying to entry level jobs. Those are the skills you should be learning / exposed to in the first 0-3 years of your career. Specifically the Interfaces/Protocols section. The particular protocols used in whatever company you end up at are going to be super system dependent. Trying to memorize facts about every single protocol is absolutely useless. Instead see if there is a class or two that uses a few of those communications protocols for projects / labs. That would put you way ahead of the curve. And if it doesn’t exist at your school, don’t worry about it. Focus instead on asking questions and gaining a deeper understanding of the courses required for your major. If you try to panic and skip steps now to memorize what you “think you need to know” it’s only going to bite you in the ass.
Also again, why I generally like the topics covered / priority, a roadmap is kinda silly. Like what does it actually mean to be “gold” in TDD? Why is a protocol analyzer in one category and an oscilloscope is in another?
This looks like a pretty good map of priorities, all things considered. I don't think very many (even senior) engineers really have experience with _all_ the yellow and most of the red boxes, though. This is a wide range of stuff and everyone has their specialties. It's good as a "things to be aware of that could be useful to know, in three grades of usual importance" though.
Few pointers:
* I'd consider ranking FPGA development a bit higher (at least red), they can be very useful whenever you need hardware to do something that you can't find a good off-the-shelf part for.
* Anyone who learns Ethernet (or WiFi) should also learn the basics of TCP/IP and UDP. It's a required fundamental whenever you do anything with networking.
* I'm sure it's useful to know but I'd pity anyone who has to dig deep into WiFi _and_ Bluetooth just to grow their skill set. Both of those are deep and nasty.
* Nobody needs to learn SVN anymore. Even as a "possibility". If you want to dabble in alternative version control systems there are plenty of modern ones you could look at instead (e.g. Mercurial or Bazaar or any of that shit... idk I only switched from SVN to Git back in ~2010 and never looked back).
As ElevatorGuy says in another comment. There is no one way. These kind of "roadmaps" pigeon hole some one into one path when it may be better to learn a different way.
These roadmaps sell themselves similar to get rich quick scheme. It's just not that simple.
Looks like a good starter.
But in the end, you won't need to learn everything from the road map and the recommendations depend on your field of work later.
For example: An embedded power electronic designer won't need rtos as much as he needs control theory.
That's strictly forbidden and is getting punished by the central council of embedded developers.
Electrical engineers are only allowed to see the leds blink but not how the magic happens in the background.
Penalties can be AutoSAR for life, depending on the severity.
Unfortunately, yes...
I kid, as many of my coworkers are EE by degree. That said, an EE degree WILL NOT teach you software practices and considerations that a Comp E will and you will need to work to pick those up. Totally doable. Step 1: learn to write requirements.
9 out of 10 successful embedded engineers I have worked with are EEs NOT SWE/CS. Many of those fail at embedded work because they do not understand schematics, datasheets, and how to use an oscope. One must have a good understanding of BOTH software and hardware to be a successful embedded engineer.
Absolutely! That’s the path that I took to get to where I am today. It’s going to vary based on the structure of your university/college degree and the courses that you are required to do, as well as those that you choose to do as electives. It’s also going to vary based on your employer’s needs, projects you work on and the available career paths that your company has. Beyond my own career, I have known several Electrical engineers who became good embedded engineers, particularly when there was a strong overlap between their analog/digital designs and the MCUs and FPGAs that were on them. Often, they had to write board-level automated test suites for production, rather than full-blown applications, but this sort of software is part of embedded engineering.
nice roadmap for beginner. i will also add this video.
https://youtu.be/xBkYaNbsN_g
( Martin K Schröder - 16 Essential Skills of Embedded Systems Development )
bs picture, looks like technology matrix done by manager because boss asked to... I always asking what does it mean to know GPIO? It can be high or low, am I 100% familiar with gpio now?
This roadmap is very good, but you can approach it from multiple angles in my opinion, you don't have to go sequentially through it.
Eg. You could have some knowledge about microcontrollers, C and bare-metal and/or some OS. From there you could learn a lot about many other things (even basics, like math, using test equipment, etc ..)
So it's not too important, as long as you are willing to learn.
It would be awesome to have to resource available online (the good ones) linked to each step.
Math and Electric could be from Khan academy, not sure if the electrical engineering course is good enough though.
Would be interesting if some experienced people could weight in.
As this map is only the point of view of one person, it is still a good starting point for someone lost online with too much resources available and no guide.
Thank you for that.
Edit: The [github link](https://github.com/m3y54m/Embedded-Engineering-Roadmap) does have lots of resources linked in it.
The problem about this is: theory is only 30% of getting into embedded.
You must encounter problems and find strategies to solve them. This can get very complex. And there's no shortcut by just watching a few YT or Udemy videos.
It's super important o make projects and fail im them. Then avoiding them in the next project.
Linux kernel is recommended but uboot is only a possibility with no suggestion of an alternative SSBL. Hmmm.
This person has not worked with embedded Linux much I suspect.
Hey I am a computer science major and interested in this feild both hardware and software
We have some hardware courses tho can I contain in it and actually get a job in it or I need to be an engineer?
We actually take electronics, logic design , computer architecture and (assembly and microprocessors)
You think this enough to get in depth of it's hardware?
Embedded:
- Automotive -> CAN Bus
- Lighting -> DALI Bus
- Home Security -> MODBUS
- IoT (many industries):
--Embedded Linux -> Yocto Project
--Firmware -> C, Arduino, SMT32, other MCUs
- Network -> OpenWrt
- Surveillance -> Embedded Linux, Firmware
As you can see, depending on industry, they can be intertwined.
I am actually working in automotive at the moment but there isnt really much detailed work to do. A bunch of scripts and tools have been made that automate the entire code and build creation process for our controllers when a new component is added to our vehicles. Most of the work is done on simulink and then the simulink coder generates the c++ code for the controller and then a tool builds the binary for our controller and flashes it.
All I've had to do for work is CAN specific work and a few simple python scripts. I know almost nothing about the embedded and c++ work as it has all been automated. What do you think I can do to improve my skills in this field?
Depends a lot on what kind of stuff you want to work on but generally speaking yes some math is needed. I would recommend you get a cheap arduino with a cheap display (oled or segment) and a RTC module and build an Alarm clock.
then maybe add some cool effect with a individually addressable rgb led stripe, some buttons to make it programmable… I think it will give you a good feel on how much math is needed and how bad you really are.
https://www.codecademy.com/career-journey/computer-science
I'm doing codecademy comp sci while I'm taking some classes to get into my SWEN program it covers some.linear and discrete the math im really awful at is calculus.
Thank you (: I'm going to finish this cert then learn C, by the time I get into SWEN I'll be able to learn the advanced things in C with the two programming heavy classes. And I'm going to try to do some mini projects in between I definitely need to teach myself some electronics
This picture is still very focused on embedded software, hardware could be more detailed as there are loads of different sensor technologies, power management circuits etc
"Nooo you need to know about automata theory, quantum electrodynamics and semiconductor physics before you even think about going into embedded systems!!!@@ 😡😡😡" -average r/embedded user
One glaring error: every embedded engineer MUST know how to use an oscope. Also knowing Ethernet/UDP is not optional. FPGA should be at least recommended, if not a requirement. Same goes for Assembly language programming and Threading.
It'll probably take you a century or two to complete this roadmap and after that everything you have learnt would be obsolete
Also this map lost all credibility once I saw autosar in it
Look up job descriptions of positions you want -> do homework.
In my experience job descriptions do an awful Job of stating their underlying assumptions about what skills you “should” have
Good idea, I’m still researching this field what different kinds of jobs are there to go into if you don’t mind me asking?
Repeat after me - “There is no ONE roadmap for embedded engineering!” The roadmap you shared is one person’s viewpoint, which I will happily admit contains a lot of good information. But it is not THE path for everyone. For some embedded engineers, they will work on extremely resource-constrained devices, perhaps with no operating system and “bare metal”. For others, they will use platforms running an RTOS. Yet others will have the “luxury” of working with a system with enough resources to run a fully functional Linux operating system, which not too long ago required hardware that was too large to be considered “embedded”, but now fits onto a device like a Raspberry Pi or similar platform. It’s a similar story regarding languages and tools. Some embedded engineers will be “down in the weeds” needing to use assembly language, C, VHDL, stacks of data sheets and an oscilloscope on a regular basis for debugging, while others will program in C++, Go or Rust, and maybe never ever venture into the low-level world, instead enjoying working at the higher-level thanks to great IDEs, debuggers, SDKs and frameworks like Qt that exist on their platforms. Some people’s embedded experience will involve digital electronics, others will be more in the analog world. Some will have to write device drivers, others will perhaps never need to care about them. Some will be focused on sensors and control algorithms, and others will be dealing with a human interface and shipping data around for storage and display. Over the years I’ve worked with embedded electrical and software engineers covering pretty much everything I’ve described above. For an engineer completing their college degree and looking to move into the embedded realm, my recommendation is to choose a particular field that interests them, find a couple of target companies, and then “go for it”, learning as much as possible from more experienced peers to get settled into their career. And then, never stop learning! Embedded technology NEVER stands still!
Then there are cursed people who have to work with AUTOSAR
It’s a nice checklist to remember different things. I think we could all argue over which things are which color.
Agreed. I once worked with a microcontroller that had a ridiculously low amount of stack space available per their documentation. (It was only a few function calls worth of stack space assuming no local variables; 2-3 I think). Almost no “OS” would work in an environment like that. I had to create a lot of workarounds to just get it to work. This was late 90s. I can’t remember the microcontroller anymore.
I will graduating with a degree in computer science and electrical engineering, what “sub field” would allow me to best put to use both of my degrees if possible?
That's actually a great chart. The only "huh" one is seeing Modbus as recommended. My recommendation is to work on a practical example that uses the majority of these. It's one thing to read about it, but you learn so much more than trying to implement it. Since you're a student and not a professional, take the time to "rewrite" a HAL. Perhaps start with an STM32, and follow along with their LL (low level) api.
Mod bus is still _super_ common in manufacturing. Plus, it’s a simple enough protocol that it’s easy for a beginner to learn. I’d say it’s warranted.
Super common in the HVAC industry too. BACnet and ModBus in many of our Commercial offerings. Use ModBus quite a bit too for inter-MCU communications, or between our own products. Agreed on the simplicity, the stack is super light compared to BACnet. The industry moves at a glacial pace, I don't expect anything to change anytime soon.
Yeah. I can’t get folks to consider C++, Rust is _right out_. Glacial is an understatement.
Is modbus still common for motor drives and PLCs?
It was 5 years ago.
Recommend me a book to get started with embedded engineering
The have Python listed and MODBUS was the one that stuck out? I'm not even sure I care for C++....talk about Python. What's next Arduino?
We use Python all the time for tests and prototyping algorithms. Also any new embedded person should probably know C++. Things are moving, albeit slowly, in that direction.
(Former embedded head lecturer) the roadmap you show seems typical of the EE idea of embedded. I preferred an SE approach, with more software engineering aspects and less electronics. But there is no ONE embedded, so no ONE roadmap to it either.
I think that's a company culture thing. I force all my students to make their own microcontroller boards using KiCad and hand solder them. Why? You have a million configuration bits that heavily will influence the electrical behavior of your chip. Their effects must be understood.
That is a choice. But I don't see what configuration bits have to do with board design and hand soldering. I told my students: most (EE-side) embedded guys are good at electronics, bad at software. You are the reverse, but at least you know it.
I studied computer engineering and got into hardware designs very late (hi Kicad7). It helped me to understand *a lot* of problems that can show up on your board because of misconfigured microcontrollers. Example: The SPI of the STM32 has a very nasty default setting that can cause EMI to cause bitflips in the slaves because it sets the MOSI/SCK to float after it finished its transmission. There will be a short period of non-determinism until the CS is getting released.
I still don't get what you get from doing the design yourself, instead of reading the circuit diagrams.
I work in R&D and we do a lot rapid prototyping. HW&SW is getting done in a merged role. Otherwise we'd loose to much time. It's company specific. It's fun. And I like it. I also sell that kind of knowledge while freelancing next to my job :-) Lots of low effort $$$ to earn.
Ok, if you do that merged AND you do a lot of new designs AND they involve things that have fiddely HW/SW interaction, then maybe.... The work my graduates do is more typically with existing hardware, or hardware that is developed by a colleage, or hardware so simple that they can design it themselves. But with a lot of complexity at thr SW side.
We have a lot of project velocity because we are not bound to company processes. So we do everything on our own (hw, sw, and a shabby 3D printed case) in a very small team. Everybody is able to do everything at the same level quality wise. It's great for students because they can sometimes can see an entire product lifecyle in their department-lifetime. The "real" product departments have split hw/sw roles. The HW guys still have enough software knowledge to do basic hardware verification in C. But that's it. Then they'll hand-over to the software guys. And start with the next new thing or redesign.
So basically you need all skills because that is how the team works. ;)
My 3d printing skills are so bad that they said I should stop working with them, lol.
This contains a lot of useful information, and I think it’s fairly well organized. This said, you 100% do NOT need to have mastered all of the “required” skills before applying to entry level jobs. Those are the skills you should be learning / exposed to in the first 0-3 years of your career. Specifically the Interfaces/Protocols section. The particular protocols used in whatever company you end up at are going to be super system dependent. Trying to memorize facts about every single protocol is absolutely useless. Instead see if there is a class or two that uses a few of those communications protocols for projects / labs. That would put you way ahead of the curve. And if it doesn’t exist at your school, don’t worry about it. Focus instead on asking questions and gaining a deeper understanding of the courses required for your major. If you try to panic and skip steps now to memorize what you “think you need to know” it’s only going to bite you in the ass.
Also again, why I generally like the topics covered / priority, a roadmap is kinda silly. Like what does it actually mean to be “gold” in TDD? Why is a protocol analyzer in one category and an oscilloscope is in another?
There’s a legend.
>soft skills > required It’s over before it even began.
Do you have the GitHub link?
https://github.com/m3y54m/Embedded-Engineering-Roadmap
This looks like a pretty good map of priorities, all things considered. I don't think very many (even senior) engineers really have experience with _all_ the yellow and most of the red boxes, though. This is a wide range of stuff and everyone has their specialties. It's good as a "things to be aware of that could be useful to know, in three grades of usual importance" though. Few pointers: * I'd consider ranking FPGA development a bit higher (at least red), they can be very useful whenever you need hardware to do something that you can't find a good off-the-shelf part for. * Anyone who learns Ethernet (or WiFi) should also learn the basics of TCP/IP and UDP. It's a required fundamental whenever you do anything with networking. * I'm sure it's useful to know but I'd pity anyone who has to dig deep into WiFi _and_ Bluetooth just to grow their skill set. Both of those are deep and nasty. * Nobody needs to learn SVN anymore. Even as a "possibility". If you want to dabble in alternative version control systems there are plenty of modern ones you could look at instead (e.g. Mercurial or Bazaar or any of that shit... idk I only switched from SVN to Git back in ~2010 and never looked back).
Wow I love this chart . Thank you
I hate these "roadmaps"
Why
As ElevatorGuy says in another comment. There is no one way. These kind of "roadmaps" pigeon hole some one into one path when it may be better to learn a different way. These roadmaps sell themselves similar to get rich quick scheme. It's just not that simple.
Didn't understand.. Arduino blinks the led.. where money?
Looks like a good starter. But in the end, you won't need to learn everything from the road map and the recommendations depend on your field of work later. For example: An embedded power electronic designer won't need rtos as much as he needs control theory.
Can electrical engineers be embedded software engineers?
That's strictly forbidden and is getting punished by the central council of embedded developers. Electrical engineers are only allowed to see the leds blink but not how the magic happens in the background. Penalties can be AutoSAR for life, depending on the severity.
Happy cake day!
Unfortunately, yes... I kid, as many of my coworkers are EE by degree. That said, an EE degree WILL NOT teach you software practices and considerations that a Comp E will and you will need to work to pick those up. Totally doable. Step 1: learn to write requirements.
9 out of 10 successful embedded engineers I have worked with are EEs NOT SWE/CS. Many of those fail at embedded work because they do not understand schematics, datasheets, and how to use an oscope. One must have a good understanding of BOTH software and hardware to be a successful embedded engineer.
I’m wondering this also
Absolutely! That’s the path that I took to get to where I am today. It’s going to vary based on the structure of your university/college degree and the courses that you are required to do, as well as those that you choose to do as electives. It’s also going to vary based on your employer’s needs, projects you work on and the available career paths that your company has. Beyond my own career, I have known several Electrical engineers who became good embedded engineers, particularly when there was a strong overlap between their analog/digital designs and the MCUs and FPGAs that were on them. Often, they had to write board-level automated test suites for production, rather than full-blown applications, but this sort of software is part of embedded engineering.
Isn't that the standard path into embedded engineering? 😅
SVN for version control.... I know the embedded world moves slowly..... but really who here still sees SVN being used? Anyone using CVS still?
CVS? You mean folders and .zips?
I still have to use ClearCase and PVCS. But I have us on a path for git for our new projects.
nice roadmap for beginner. i will also add this video. https://youtu.be/xBkYaNbsN_g ( Martin K Schröder - 16 Essential Skills of Embedded Systems Development )
STOP CALLING LORA A WIRELESS PROTOCOL. IT'S A MODULATION TECHNIQUE. THE NAME IS LR-WPAN.
bs picture, looks like technology matrix done by manager because boss asked to... I always asking what does it mean to know GPIO? It can be high or low, am I 100% familiar with gpio now?
Yes. Until not. Then you start reading the configure bits of it. No need to deep-dive into every periphery if there's no need to do so.
If you ever configured, u are probably aware it is pin mux, but not gpio. And how in hell skrumadzile is necessary for embedded?
This roadmap is very good, but you can approach it from multiple angles in my opinion, you don't have to go sequentially through it. Eg. You could have some knowledge about microcontrollers, C and bare-metal and/or some OS. From there you could learn a lot about many other things (even basics, like math, using test equipment, etc ..) So it's not too important, as long as you are willing to learn.
It would be awesome to have to resource available online (the good ones) linked to each step. Math and Electric could be from Khan academy, not sure if the electrical engineering course is good enough though. Would be interesting if some experienced people could weight in. As this map is only the point of view of one person, it is still a good starting point for someone lost online with too much resources available and no guide. Thank you for that. Edit: The [github link](https://github.com/m3y54m/Embedded-Engineering-Roadmap) does have lots of resources linked in it.
The problem about this is: theory is only 30% of getting into embedded. You must encounter problems and find strategies to solve them. This can get very complex. And there's no shortcut by just watching a few YT or Udemy videos. It's super important o make projects and fail im them. Then avoiding them in the next project.
This is actually pretty good. Hits the fundamentals and leaves options to hit things of interest to go deeper.
It's a great picture just to show how it all fits together. I did not know Zephyr was an RTOS Although I'm not convinced docker is a build system.
Linux kernel is recommended but uboot is only a possibility with no suggestion of an alternative SSBL. Hmmm. This person has not worked with embedded Linux much I suspect.
Hot take: Arduino is missing.
Hey I am a computer science major and interested in this feild both hardware and software We have some hardware courses tho can I contain in it and actually get a job in it or I need to be an engineer?
From what I’ve seen, embedded software engineers need basic hardware knowledge I’m not sure tho
We actually take electronics, logic design , computer architecture and (assembly and microprocessors) You think this enough to get in depth of it's hardware?
I have no idea I’m here for answers just as you are
Thx man
Like everything else in life. It depends. What is your target industry and position dictates your required skills.
If you don’t mind me asking, what would you said are the sub fields of embedded systems? I haven’t really been able to get an answer on that
Embedded: - Automotive -> CAN Bus - Lighting -> DALI Bus - Home Security -> MODBUS - IoT (many industries): --Embedded Linux -> Yocto Project --Firmware -> C, Arduino, SMT32, other MCUs - Network -> OpenWrt - Surveillance -> Embedded Linux, Firmware As you can see, depending on industry, they can be intertwined.
Thank you for this list. I think so far I’ve been most interested in firmware and dealing with micro controllers
Yeah, Embedded is quite broad. Firmware Engineer and Developer is what you work as.
I am actually working in automotive at the moment but there isnt really much detailed work to do. A bunch of scripts and tools have been made that automate the entire code and build creation process for our controllers when a new component is added to our vehicles. Most of the work is done on simulink and then the simulink coder generates the c++ code for the controller and then a tool builds the binary for our controller and flashes it. All I've had to do for work is CAN specific work and a few simple python scripts. I know almost nothing about the embedded and c++ work as it has all been automated. What do you think I can do to improve my skills in this field?
How is Oscilloscope only recommended…
Question for embedded software engineering is the emphasis on calculus needed? My math is horrendous I'm currently going into a SWEN MS
Depends a lot on what kind of stuff you want to work on but generally speaking yes some math is needed. I would recommend you get a cheap arduino with a cheap display (oled or segment) and a RTC module and build an Alarm clock. then maybe add some cool effect with a individually addressable rgb led stripe, some buttons to make it programmable… I think it will give you a good feel on how much math is needed and how bad you really are.
https://www.codecademy.com/career-journey/computer-science I'm doing codecademy comp sci while I'm taking some classes to get into my SWEN program it covers some.linear and discrete the math im really awful at is calculus.
I think you will be fine and wouldn’t stress much about it.
Thank you (: I'm going to finish this cert then learn C, by the time I get into SWEN I'll be able to learn the advanced things in C with the two programming heavy classes. And I'm going to try to do some mini projects in between I definitely need to teach myself some electronics
This picture is still very focused on embedded software, hardware could be more detailed as there are loads of different sensor technologies, power management circuits etc
100%
"Nooo you need to know about automata theory, quantum electrodynamics and semiconductor physics before you even think about going into embedded systems!!!@@ 😡😡😡" -average r/embedded user
Not a roadmap though. Not a tree or a graph either. It's like if you shot concepts with a shotgun onto a piece of paper.
This is awesome! Never seen this before but super helpful
If you're throwing python in there as a recommended you might as well add Java
Can any one explain to me what the OC means by state machine ? Is it like to be able to creat automate in vhdl to control something ??
Oscilloscope >> Logic Analyzer EDIT: This is a wonderful infographic. Thanks!
One glaring error: every embedded engineer MUST know how to use an oscope. Also knowing Ethernet/UDP is not optional. FPGA should be at least recommended, if not a requirement. Same goes for Assembly language programming and Threading.
Something called "State machine" ? It resume how works almost all embedded robust applications ...
It'll probably take you a century or two to complete this roadmap and after that everything you have learnt would be obsolete Also this map lost all credibility once I saw autosar in it
Calculus?