We developed the RTOS (Real-Time Operating System) for our activity trackers using the Zephyr kernel and its libraries. This is another lesson I learned the hard way by spending too much time developing a system that wasn't essential.
As a software developer working on the side to develop pet activity trackers, I wanted our software stack to be top-notch (much like many other developers when they start building their first product or startup). When it comes to firmware development, there were official SDKs from each chip manufacturer, but we chose to go with our own RTOS based on Zephyr. Why Zephyr? Because of its Linux Foundation backing, support for multiple protocols, lightweight kernel, OS APIs, and examples of complex OS features in their documentation š.
I found a great developer remotely who was an expert in Zephyr. As he started building, the more features he addedāaround Messaging Queues, Semaphores, OS Threads, Mutexes, NVM storage, and DTS bindingsāthe more I fell in love with RTOS development.
It took us a few months to develop a stable OS for our devices. We were slowed down by faults in our PCBs, faulty sensors, and other similar hardware problems. After those months, my favorite OS developer found a better opportunity near his hometown. I posted locally to find another Zephyr developer, expecting not to find many who use it. I ended up continuing the development, including minor fixes, on my own.
When it was time for mass production, I unfortunatelyāor perhaps fortunatelyācanceled the contract with our current hardware manufacturer due to the number of faults in each prototype and a significant communication gap. Switching to a different manufacturer, who already had similar devices, allowed us to adopt their PCB designs with minimal changes. Now, the MCU, sensors, batteryāeverything has changed, and Zephyr wasn't compatible with this new MCU! š
For our second firmware, we (I managed to rehire the same developer) developed it in just a few weeks instead of months by switching to official SDKs. This eliminated the need to manage custom queues, semaphores, multiple threads, mutex locks, device bindings, custom OTA, and the BLE stack, etc. The SDK managed all these features, and only two threads were sufficient to accomplish what we actually needed. It also handled OTA and the BLE stack on its own. š
Building our custom RTOS for activity trackers was an overly innovative solution. RTOS might be necessary for applications like self-driving vehicles, military devices, or handheld devices with thousands of features! However, activity tracking can be efficiently managed using built-in SDK drivers and functions.
Lessons like these elevated my software and product development skills to the next level, but they also delayed our product development timelines. I am sharing these insights one by one, hoping they will be helpful for upcoming hardware or software startup founders.
Say hello or read more posts like this at my LinkedIn profile and the activity tracker we built is PetDrifts Lite