Kospet Magic 3 smartwatch

humm ok. I think I understand now.
Thank you 🙏

Hi @fanoush, @jeffmer and @Gordon,

This is my first post here; I've been aware and following Bangle.js for a while now as I am very intrigued by the concept (and reality thanks to you guys) of running Javascript apps and app store on a watch or even smartphone. I see great potential with the "common" knowledge of JS.

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?

I'd love a new play-toy, try all sorts of apps and brush up on my Javascript skills to build my own to share :-)

Thank you

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?

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.

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 ;-)

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
https://github.com/enaon/eucWatch
https://enaon.github.io/eucWatch/
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
https://github.com/espruino/Espruino/blob/master/libs/banglejs/jswrap_bangle.c#L1270
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

hi, from you people s conservation, i see that even gordon would like to see more device could run the 4xx app in bangle store, yet its just currently some technical trick with the aformentioned xxx file that render non-official espruino port unable to use most app from the bangle store, correct?

i will buy a bangle.js v2 recently,
but i think its better to have 2nd provider, in future.

so would like to see them later could also use bangle store s app too otherwise it limits to my own apps.

thanks.

btw i am nothing a programmer compared to you guys,
but if you think gpt4 could help draft it for you, pls let me know.

i am eager to make that happen, thx

Long time ago I tried this with P8 and failed

hi, i have the same goal, using pinetime/p8 as a backup platform for bangle.js v2,
of course it would be good if pt/p8 can also run the bangle store apps like bangle1/2.

I am a layman. Do you think you and others could enlighten me so I could ask gpt4 to make a try?
As you may see my other posts, it DID wrote me a bangle app for soft-reboot, modify the "swipe back to clock"and"back swipe"'s swipe direction, also the microwave bangle app; among many other things outside bangle.

OR, if you could intelligently break it up into smaller steps, i could try to use gpt4 to do the small steps 1 at a time...etc.

ps:
I have the concept of traditional programming and some OOP, i just dont want to learn the "gramma" of 100+ languages. It's ridiculous that some use for (i++,j++) and some use for [i++;j++] etc.

ps2:
my swd tools just arrived, i am now trying to un-brick my p8b-mirror > <

I am a layman. Do you think you and others could enlighten me so I could ask gpt4 to make a try?
...
OR, if you could intelligently break it up into smaller steps, i could try to use gpt4 to do the small steps 1 at a time...etc.

So it is
ME <== forum posts ==> YOU <== chat ==> GPT4
That looks pretty complicated. It should be far more optimal if we remove the "ME" or "YOU" part from the loop :-)
However the idea to let GPT4 refactor it is good so please go on if you feel so.

@ccchan

I don't see

learn the "gramma" of 100+ languages

to be the issue here...

It is the 'cartesian product' of all the nitty gritty deltas of all the components that have to play nice with each other by code that does not break the 'resources' bank.

Infrastructures and frameworks that can handle the deltas of various hardware platforms are generally very bloated not only in respect to static resources - code memory - but also in respect to dynamic resources - variable memory and cycles - at runtime. Build-time effort left by the side.

Therefore, picking and focusing on (just) a few 'animals' that are 'biologically' compatible is the requirement for (economic) sustainability.

For me, Espruino ecosystem can claim the Guiness World Record for biodiversity, hackability, resourcefulness, robustness,... and is vibrantly alive (has survived many others).

Hey @fanoush, do you have any plans to still work on the kospet magic 3? I was wondering if I should get one, so that I have something that I can tinker around with, without breaking my daily driver bangle.js... but if this is a dead end, I'd rather wait for another opportunity to get some cheap toys to play with

I was wondering if I should get one, so that I have something that I can tinker around with, without breaking my daily driver bangle.js... but if this is a dead end

Your choice really, it depends on what you want to do with it, it is not a Bangle.js watch that can run bangle apps out of box, it is cheap nrf52840 Espruino device with battery and touchscreen that can run your custom code. All the hardware (except maybe HR sensor) works and is usable. If you want to tinker then go ahead - it seems to work for cat litter boxes https://forum.espruino.com/conversations/392685/?offset=25#17537542

EDIT: and if it was not clear it can be also used as a watch either with custom code or it can run some subset of banglejs apps but you need to maintain them yourself (including matching bangle.js runtime)

If you want to tinker then go ahead - it seems to work for cat litter boxes

hahaha :)

The magic3 with your display driver is super for under 15 euros.

I placed a 10pins plug where the charging pins were, so I got Vin, V batt, gnd, i2c bus and 5 pins available, very handy device. I even got the side button working fine after mounting it to place :)

in case anyone is interested, this how to works fine for hacking it, mostly for part 2, the web ide part, it is easier from the loader I think.

https://enaon.github.io/eucWatch/tools/hackme2/

3 Attachments