Solving Solved Problems

I am currently working on an embedded system project and as
I continue along with it I have this feeling that I am solving
already solved problems.

Let me paint you a picture of the things I had to solve and my
tech stack. I chose to use the Raspberry Pi Pico as the microcontroller so that I could make use of Micropython as I am already acquainted with Python.

I could not go back to C and C++ as my skills in them had already atrophied from not using them actively in more than 3 years. I had also not engaged in any meaningful embedded project in that time. Below is the tangled mess of the breadboard prototype.

One of the first problems I had to solve was how to create an abstraction to use shift registers as my means for input and output. The aim being to conserve the number of pins I would use in the board. This took more time than I had initially anticipated and I only searched if there was a solution for it after being done coding it. The solution I found had some similarities with the one I had made and it was from 4 years ago. I did not regret it since my solution was more flexible and tailored to my code structure.

Most of the libraries I was creating were somehow already created but
their structures were different from how I had structured mine. They were missing some functionality that I had or vice versa. So in a way I was solving solved problems but this being an embedded system that I have to understand almost end to end, I believe I did the right thing by solving them.

Another issue I tackled was logging. I have never really thought much about logging but in embedded systems it is quite crucial as you want to precisely know what your system was doing before it just crashed. Tackling this topic reminded me of business process management, whereby you can extract a business process from the logs that are there.I continue to aim for my system to be like so but I have fallen short in some ways. Add to that , that I am logging in a multithreaded program, I have 2 threads running - the pico has 2 cores - working on a multicore system is another learning journey that I am yet to complete.

The issue that made me realise finally that I have been solving solved problems is OTA - Over The Air updates. When I started working on this project I had not thought that I would need to update my code remotely. I came with my mentality from over 3 years ago when I was making toy embedded systems. I have been doing backend systems for the past years and over there this is given by default unlike in embedded systems.

From the little research I have done, most of the OTA systems seem to be for C/C++ systems. I feel I need to solve this solved problem for my Micropython code. I still emphasize about my code structure, I don't want to affect my code architecture that much. But the mere thought of what it will take to create an OTA system from scratch makes me shiver. I am sure over there too, I'll have to deal with things that I have not already foreseen.

This journey has made appreciate libraries and frameworks that have already been created and why companies pay to use proprietary libraries. Solving already solved problems sucks and is not your core business. I have learnt it the hard way. However, you learn a lot in
the process of solving them which hopefully makes you a better developer.