Kospet Magic 3 smartwatch
Hi @fanoush, @jeffmer and @Gordon,
You guys are awesome! I am clueless as to why this has not gotten way more attention.
Why post here? I'm considering getting the bangle.js2 just to play with or even wear on a daily base. My WearOS2 watch died on me and I am eager for a replacement that provides notifications (and time). However, I am hesistent reading the build quality issues of the js2 and was reading up on alternatives, like this topic about the Kospet 3 with its nice(r) specs.
Since the last post is a bit old; is this firmware still current and usable for future updates by @Gordon? Would you recommend getting a Kospet 3 and get it running with the steps @fanoush documented, obviously knowing it will not be bug-free and without quirks?
is this firmware still current and usable for future updates by @Gordon? Would you recommend getting a Kospet 3 and get it running with the steps @fanoush documented, obviously knowing it will not be bug-free and without quirks?
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.
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 ;-)
Well then you can try stuff mentioned in jeffmer's post #9 and see what is missing for you. It is still usable, just a bit older. Also there is stuff done by enaon
It also uses Espruino and the app loader but apps and the UI is different.
I should add that jswrap_bangle.c already supports quite a wide variety of different hardware (more than when the first extra watches were being added) so it may be that not a great deal of extra changes are needed to it to support the watch you're interested in... Also if it's a matter of adding extra hardware and it doesn't add too much bulk (things like accelerometers are usually very easy to add) then I'm open to pulling that into the main Espruino repo.
it may be that not a great deal of extra changes are needed to it to support the watch you're interested in..
Well, it may be not a great deal for you to navigate ~5700 line file and sprinkle it with few lines in ~10 places of that file for adding support for yet another accelerometer device without breaking anything.
For people like me, @jeffmer, @yngv126399 it is significantly harder to do both parts (1. add, 2. not break). And I think we actually don't need to care about maybe 3/4 of that file to add another watch and yet for now we need to learn all of it.
I think jswrap_bangle.c is the wrong file to modify when we want to add e.g. another 3 types of accelerometers or touchscreens.
Currently if I want to add bma420,bma223,sc7a20 there are couple of places like this one
Where I need to extend this spaghetti of ifdefs with three more cases (and BTW bma223 is 8 bit while others may be 12bit). When I search for
ACCEL_on that page it is all over the place. Then I get to place like this https://github.com/espruino/Espruino/blob/master/libs/banglejs/jswrap_bangle.c#L3199
and need to solve it somehow for my watch, and BTW the bma223 in my watch is connected over spi, not i2c.
Or another random example - with new watch I need to think about this line https://github.com/espruino/Espruino/blob/master/libs/banglejs/jswrap_bangle.c#L1506 whether my watch is like F18 or not (whatever F18 actually is, I may not know). There are many place like this there.
Basically just for adding one watch out of many I would need to add lot hacks/workarounds/ifdefs there, all the time thinking about all the other watches and hardware combinations already there. So it is not about adding one accelerometer type.
With rest of Espruino it is like
jswrap_storage.c (or jswrap_flash.c) calls into jsflash.c which calls into jshardware.c (jshFlashRead/Write/Erase...). When porting to another platform I can basically do just another jshardware with few jshFlash methods without thinking how storage of jsflash layer works.
For bangle_jswrap.c all those layers are not there so generic Bangle watch policy/logic is intermixed with specific hardware support. It would be much easier and scalable to implement new accelerometer X support in separate file with known interface without touching jswrap_bangle.c at all. Same for new touchscreen , display, hr sensor or gps.
Yes, understood - it is a bit of a pain for sure with all the ifdefs there.
There's also the question of devices like Puck.js that end up duplicating the code to talk to accelerometers.
I'm open to suggestions, but the problem for me is I don't really have the time to completely refactor everything, and really the only thing that can happen for me if I do it is something breaks and someone complains - nobody notices if it works.
As you noted though, some of these things interact - either they're on the same I2C wires, have to run at different I2C speeds (Puck.js) or they need to be turned on an off via an IO expander (Bangle.js 1) - it feels quite hard to pull that functionality out in a way that will completely remove the ifdefs from jswrap_bangle.c
humm ok. I think I understand now.
Thank you 🙏