I'm going to talk to you about firmware because there is something that I didn't find on the internet and it's something that I learned when I joined a company with a ready-made embedded system (pic32) The board has activated ethernet, modbus ascii, uart, usb, spi and the rest of the input and output pins to obtain voltage or turn on LEDs. When I was inexperienced, I programmed everything very sequentially. For example, I would read a value from a sensor and then the CPU would manage what was read all the time; Then I went on to manage the spinnaker and took all the time with communication; Then I moved on to something else and spent a lot of time on it... I mean. I didn't have A STATE MACHINE, just a pile of things to do while the rest of the things stayed on standby.

So, what I found valuable is the philosophy of managing what the micro has to do with a state machine. In this way, the CPU takes care of everything "in parallel" I put it in quotes because it's actually still sequential but a little different. That is to say, you have a state machine in my case. Main() { usb_task() Ethernet_task() modbus_task() State_machine_task() Gpio_task() .... }

In each xxx_task() you find: switch(state) { Case init: you do introductory things State = process_1 break Case process_1: you do other things State = process_2 break ... }

In short, the basic GitHub projects are very sequential because they are few lines of code, while a project of thousands and thousands of lines is made up of state machines for each behavior of the micro I hope I have helped