advice for getting into embedded firmware role

[bug13]

Hi guys

I have been an self taught EE for a number of years. Keen to get into an embedded firmware role in the new year if I can. Anyone done this? Any suggestions??
Thanks team!

[profanum429]

Are you looking at moving within the same company you work for or getting hired on somewhere / contracting work? Also, what type of embedded firmware? General purpose stuff on a SBC running Linux, higher power bare metal applications using a M series Cortex, or low power devices on tiny PICs or Atmels, or something totally different?

[unitedatoms]

I did this. Being a software person for decades and having electronics as a hobby. I set a goal to learn everything involved in making a physical products. At every turn chose a job closer to design and actual physical manufacturing. I kept blogging about electronics and eventually got a firmware position.

[rstofer]

How much programming experience do you have?  Not that it will matter because embedded is a different animal.  Hopefully you are at least proficient in C.

Then there is the matter of uC hardware and, more to the point, the datasheets.  You will need to truly understand portions of the datasheet and specifically the sections you plan to use.  Serial protocols (I2C, SPI, UART), timers, interrupts, PWM and all the other peripherals.

Yesterday I was commenting on this Instructable and how I thought is was a great tutorial on low level programming.  Forget the 'Arduino' part because that isn't used much.  Everything is done directly to the hardware.  Bit twiddling directly to the registers, that is embedded programming!

https://www.instructables.com/id/Girino-Fast-Arduino-Oscilloscope/

So, grab the ATmega 328P datasheet and start working through the project.  There's a lot of embedded education in one small project.  If you don't have an Arduino UNO, you should probably get one.

No, it's not a decent scope except for very limited applications but the relationship between the project goals, the physical hardware, the register settings and the overall program flow are well worth your time.

[rstofer]

Next step up:  Get an ARM board, I would choose the mbed LPC1768 (because I have some) but any of the STM32F boards should work as well.  Implement FreeRTOS (it's ok to cheat and use a board that matches one of their examples).  Add in FATfs (FAT FileSystem) and work through file systems.  Given a console, you should be able to implement a workable CP/M like system with real-time capabilities.

Maybe you use DMA for the data transfer to and from an SD card.  Clearly there will be several concurrent tasks and you can add as many as you like.

Now you're starting to catch on to embedded programming.  Twiddle bits, RTOS, File System, Console, interrupts, timers, DMA - all that stuff.

[bug13]

Are you looking at moving within the same company you work for or getting hired on somewhere / contracting work? Also, what type of embedded firmware? General purpose stuff on a SBC running Linux, higher power bare metal applications using a M series Cortex, or low power devices on tiny PICs or Atmels, or something totally different?

Most likely to a different company, as the company I am working at is pretty small. Not much room to move around. I am more interested in higher power bare metal/RTOS stuff and SBC running Linux. I have already done a lot on low power stuff on PICs/AVR/MSP430 etc...

[bug13]

I did this. Being a software person for decades and having electronics as a hobby. I set a goal to learn everything involved in making a physical products. At every turn chose a job closer to design and actual physical manufacturing. I kept blogging about electronics and eventually got a firmware position.

Thanks for sharing, that's encouraging.

[bug13]

Next step up:  Get an ARM board, I would choose the mbed LPC1768 (because I have some) but any of the STM32F boards should work as well.  Implement FreeRTOS (it's ok to cheat and use a board that matches one of their examples).  Add in FATfs (FAT FileSystem) and work through file systems.  Given a console, you should be able to implement a workable CP/M like system with real-time capabilities.
Maybe you use DMA for the data transfer to and from an SD card.  Clearly there will be several concurrent tasks and you can add as many as you like.
Now you're starting to catch on to embedded programming.  Twiddle bits, RTOS, File System, Console, interrupts, timers, DMA - all that stuff.

The FreeRTOS stuff, do you mean use the auto config tool in CubeIDE? Or implement it from scratch?

[Berni]

Id call linux development more along the lines of "embedded software" instead of just firmware.

The line between little microcontrollers and powerful chips still running baremetal is pretty blurred these days. You can buy ARM microcontrollers that run at 400MHz with a double precision floating point unit and everything. But programming one of these is no different than any other more advanced 16 or 32 bit MCU, it all runs C code, drivers work the same way...etc but this one just executes it much faster with its speedy clock. Often they are run without a RTOS or anything too, just C. If know how to program 16bit PIC then you can program a 400MHz ARM CortecM7 just as well after figuring out the new vendors tools.

Getting something like FreeRTOS running on your chip is not all that difficult as long as your CPU family is among the officially supported ones. You just take the example project and modify it to compile for your exact chip and done. If its not supported then you can have quite the adventure porting FreeRTOS to the new CPU family where you dig trough assembler code to do the low level stuff like context switching the CPU to a new thread (But can be an excellent exercise in really low level development of directly touching CPU registers).

But when it comes to linux that is a whole new ball game. But it splits into two parts, low level kernel work and application development. These two are often not done by the same person. The low level guy is the one who makes sure linux actually boots and has working drivers, services..etc, working on this requires deep knowledge of how linux works and is not easy. But then there is also the guy who develops the application, this part is completely the opposite, they don't know anything about the hardware. To them it is the same if they are making an app for a car infotainment system or a PC application, they just write it in whatever programing language they want and the OS makes sure it runs. So its just software development in general.

So if you want to get started with linux all you have to do is install a linux distro of your choosing on your PC (Or in a VM) and start writing software for it. Same kind of OpenGL libraries are used for doing hardware accelerated graphics be it the latest and greatest Nvidia RTX 2080 Ti gaming card or the GPU built into a mobile phone SOC. Tho i will admit running it on a full sized PC does not feel very embedded. But luckily you can get yourself a Raspberry Pi SBC and work on that. It runs linux and has the same sort of ARM SOC chip that you will find in most embedded linux devices. You also get GPIO pins so you can interface to hardware directly. Because the Raspberry ecosystem is so popular means there is plenty of information online on how to do stuff.

[rstofer]

Next step up:  Get an ARM board, I would choose the mbed LPC1768 (because I have some) but any of the STM32F boards should work as well.  Implement FreeRTOS (it's ok to cheat and use a board that matches one of their examples).  Add in FATfs (FAT FileSystem) and work through file systems.  Given a console, you should be able to implement a workable CP/M like system with real-time capabilities.
Maybe you use DMA for the data transfer to and from an SD card.  Clearly there will be several concurrent tasks and you can add as many as you like.
Now you're starting to catch on to embedded programming.  Twiddle bits, RTOS, File System, Console, interrupts, timers, DMA - all that stuff.

The FreeRTOS stuff, do you mean use the auto config tool in CubeIDE? Or implement it from scratch?

Either way works.  The educational bit is in adding tasks, scheduling, prioritizing, queues, semaphores and that kind of thing.  Everything is a task and it all needs to cooperate.  No deadlocks, no lack of response, no lost data, etc.

Oddly, the mainline code may run as the lowest priority.  This isn't how it works when things are scheduled in a 'superloop' design.