You are reading a single comment by @Chriz and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@Chriz
It took some time to sort out my thoughts about modularization.
This is how I started. Jswrap_bangle.c was hard to understand because of the ifdefs. And even the small bootloader main.c code was hard to read and I think there might be some ifdef combinations that won't work together. Finally I implemented my code only for the bangle js 2. That makes it easier to test and less risky but the other watches don't benefit.
Is all this really a problem? I think it depends on the goal for your OS (and especially the bangle code). Do you want it to be an OS ike linux to be run on am almost unlimited range of hardware? This would mean a lot of work to add a hardware abstraction to the bangle code and who would use it because most watches, etc are closed for custom firmware.
So I think it is more attractive to make the bangle code for your own limited set of watches with it's own ecosystem and apps.
Thinking about a bangle js 3 there could still be some improvements like less ifdef nesting or even everything related to one device in one file instead of supporting 3 (and then 4) devices in one jswrap_bangle.c file.
There is a lot of potential for the bangle ecosystem to focuse on like more UI abstraction so apps once developed run on different devices, integrated companion app extensions like e.g. the zepp os architecture (maybe gadgetbridge could be the host) and of course a new bangle js 3 hardware. Maybe api levels and storage seperation.