You are reading a single comment by @w00ter and its replies.
Click here to read the full conversation.
-
Hi @fanoush,
Thank you for taking the time to reply and explain the underlyings of Bangle.js and Espruino. Appreciate it.
I see the issue with the way jswrap_bangle.c is built. Splitting the bangle.js layer from the specific hardware layer would make it much more scalable.
If only someone knowledgeable enough would dare to take on this task ;-)
w00ter
Hi @w00ter,
I'd say go for it if you are (or want to be) Espruino hacker. If you only want to write Bangle apps in existing apps ecosystem then get real Bangle.js.
It is not that the main issue is about code for Magic/Rock (and many more watches like this) being not bug free/without quirks. It is about stuff missing as described in first ~6 posts of this topic. So if you are OK with it and want to invest extra effort like e.g. jeffmer did to reimplement enough to get some apps working then go for it.
It is also possible to try to add support for some additional watch directly to Espruino so it is on same level as Bangle 1/2. I think the first step would be to modularize jswrap_bangle.c as mentioned in post #4 so that the bangle.js layer on top of espruino has no hardware specific stuff inside. The core of Espruino is done like that - you have stuff in src/ and then you have jshardware or bluetooth implementations inside targets/* For bangle.js there is no such abstraction so you can't just implement same methods for other watch easily. jswrap_bangle.c is mix of common functionality you don't want to touch with lot of ifdef-ed driver code for specific hardware.