I have been doing embedded for a number of years. I'm the only fulltime SWE at my company and it just gets exhausting managing 5 different products on completely different code bases/technologies. Plus a web portal that does device management and reporting.
So a big thing people should consider when building something to scratch. Am I making something I can use again when I make my next product. Its a much higher mental load if you have no commonality between products. Also it can cause problems for sales, support and management when they have to remember nitty gritty details about each of your very divergent products.
Absolutely true. One of the things I learned decades ago as a solo entrepreneur was to force for as much commonality as possible across everything I was doing.
When you wear many hats you have to mentally task switch between domains and this time can sometimes be measures in weeks (example: you've been doing mechanical design and you now have to switch to FPGA design after months of not touching the codebase).
This is why jumping on the latest and greatest trends isn't always the best idea. Languages, tools, frameworks, new chips, new FPGA or CPU architectures, etc. Things that don't mesh at a certain level impose a cognitive load that can really slow you down.
The simplest example of this I have from years back would be using C and Verilog on embedded systems. While Verilog is not software, it's hardware the "C" feel to the language --as opposed to VHDL-- makes for an much easier transition between hardware and software development, at least for me.
Sounds like my day job of the last 10 years or so.
Although I'm mostly focused on the app code, I spent about four months this year debugging various wifi stacks (one for each generation of product). Only to have most of the problems fixed by moving all products to a 5.7 kernel base. Which was no easy project in itself, but mostly not my work.
In my experience, the processor, memory, flash, and all other things combined are trivial compared to getting reliable wifi.
That's good that 5.7 fixes some of the wifi issues. I actually ended up forking the driver for our particular usb wifi device and hacking whole sections of code out of it. There were some optional things that would just randomly crash the kernel (4.x).
At a casual glance it looks like your products are mostly [processor] connected to a network of CAN and/or 4-20mA devices. Not possible to back-port newer control modules to older product lines?
That said, impressive that you are handling all of it on your own. Hire somebody!
I have a couple contractors I bring in part time when I need some heavy lifting on the embedded or web side.
I have back-ported somethings, but really a large chunk of the products had terrible technical decisions before I started. I spent the first couple years just dragging the company back from the technical and financial brink. I'm slowly eliminating old products from our sales sheet in favor of ones I engineered. So it will eventually be ok.
So true. Switching from one vendor to another is a huge deal. Documentation, code bases, tool chains, etc. require a huge investment in time. It's easy to do a quickie hobby project on a new micro but for a product you really want to internalize the details.
The fact that almost everything is ARM now makes it a lot easier but the on-chip peripherals and tools are usually still very idiosyncratic.
So a big thing people should consider when building something to scratch. Am I making something I can use again when I make my next product. Its a much higher mental load if you have no commonality between products. Also it can cause problems for sales, support and management when they have to remember nitty gritty details about each of your very divergent products.