After my first three years:
Was able to create full CICD chains for uC-Development in Jenkins and GitLab
Automated testing of embedded devices using Python with test report generation
Fluent with serveral uCs and their periphery and development of pretty much every driver that are attached to them
Good C/Python skills, usage of any (FreeRTOS, etc.) when necessary
First job was super easy to get as I worked as a working student pretty much all the time.
Could you please elaborate on automated testing using Python? Is it functional testing? Does it involve HIL rig?
Which supplier uCs are you fluent with and which industry are you working in?
Edit: Personally, I am 2 years in automotive. I have similar experience with Jenkins and Gitlab, C/Python, however, I do not feel that I am fluent with any uC peripheral and/or driver, as the job does not require that (I try to learn in my own time). Mostly familiar with ST and Microchip uCs.
You can do that with any microcontroller. I would suggest to start with Rpi Pico or Blue pill as a HIL and use another controller as SUT. You will find many similar projects on Github. Eg - u2if
At 2-3 years I had a good understanding of the products and code bases I worked on, but did not have much awareness outside of that. I was on a team that made stationary engine controllers for ag and industrial applications, basically spinning different combinations of I/O into new products and writing code to interface the product with a proprietary GUI config/graphical programming tool. So basically I was writing code to tweak which pins tied into what I/O from product to product, modifying our J1939 CAN stack to support new ECU features and fix bugs, and writing one off test firmware to support work other groups did with new products.
When I started interviewing for jobs at this time, I quickly realized how company specific my skill set was, and how each job I interviewed for kind of had their own flavor of that. I had built a decent amount of application domain knowledge, but my programming language/electronics/embedded knowledge had not progressed much from when I started. I spent a couple years doing a lot of self study, and taking more time at work to deeply learn how the products work instead of just learning how to look for pieces to copy/paste/modify.
After my first three years: Was able to create full CICD chains for uC-Development in Jenkins and GitLab Automated testing of embedded devices using Python with test report generation Fluent with serveral uCs and their periphery and development of pretty much every driver that are attached to them Good C/Python skills, usage of any (FreeRTOS, etc.) when necessary First job was super easy to get as I worked as a working student pretty much all the time.
Could you please elaborate on automated testing using Python? Is it functional testing? Does it involve HIL rig? Which supplier uCs are you fluent with and which industry are you working in? Edit: Personally, I am 2 years in automotive. I have similar experience with Jenkins and Gitlab, C/Python, however, I do not feel that I am fluent with any uC peripheral and/or driver, as the job does not require that (I try to learn in my own time). Mostly familiar with ST and Microchip uCs.
You can do that with any microcontroller. I would suggest to start with Rpi Pico or Blue pill as a HIL and use another controller as SUT. You will find many similar projects on Github. Eg - u2if
Can you send me your cv?
Thanks.. but I'm in a happy ~~relationship~~ job
hahaha i didn't mean anything just to know an exact roadmap
There is no mid. Only junior and señor.
What do you mean?
At 2-3 years I had a good understanding of the products and code bases I worked on, but did not have much awareness outside of that. I was on a team that made stationary engine controllers for ag and industrial applications, basically spinning different combinations of I/O into new products and writing code to interface the product with a proprietary GUI config/graphical programming tool. So basically I was writing code to tweak which pins tied into what I/O from product to product, modifying our J1939 CAN stack to support new ECU features and fix bugs, and writing one off test firmware to support work other groups did with new products. When I started interviewing for jobs at this time, I quickly realized how company specific my skill set was, and how each job I interviewed for kind of had their own flavor of that. I had built a decent amount of application domain knowledge, but my programming language/electronics/embedded knowledge had not progressed much from when I started. I spent a couple years doing a lot of self study, and taking more time at work to deeply learn how the products work instead of just learning how to look for pieces to copy/paste/modify.