You are reading a single comment by @fanoush and its replies. Click here to read the full conversation.
  • First i just want to say, it think @Gordon approach is the best open source watch platform by a long shot. These thoughts are just my attempt at making it more universal.

    2 repo's worse then a single one

    So this is true that there would be some copying from the main repo to the generic.

    But to help mitigate this what i would do is move all the JS wrapper functions calls to separate file and they would just call a single c function. If you remove all the code and just leave the JS wrapper calls its around like 1800 lines of code that would be shared. Since it's a single call it will be optimized away.

    Also there's a good amount of device specific code that wouldn't need to be migrated over. So its only code thats completely generic.

    Code placement

    So in a perfect world. Where i would like this is.

    Espruino/libs/banglejs/alt_banglejs

    This folder would be a separate github repo. So it wouldn't mess with the main code. But it could benefit from all the changes from the general espruino improvements.

    In this folder you could also put the pythonBoard files

    Hard problem of devices working differently and being efficient

    So the approach i'm thinking of is going to 100% reduce some efficiency's. But all abstractions will cause this. But the lack of abstraction is probably part of the reason why not many watches have been ported to banglejs. Know i don't know if its worth it, But i think its worth a look into how it might be done. That's why i'm trying to make a little test bed and play around with it.

  • But the lack of abstraction is probably part of the reason why not many watches have been ported to banglejs.

    For me it is one of the reasons.

    Another one is that I think there is too much stuff hardcoded in C. I came to Espruino because I did not like this way of developing in the first place :-) I'd prefer to have more stuff done in JS and if that is slow then improving the engine or moving only the speed critical (and/or as generic as possible) code into the C side. So all the pin numbers, LCD initialization data, memory allocations (like framebuffer) could be called from some js outside of the main binary. In linux kernel they use device tree (dtb files) or kernel modules, here small pieces of js/json could do the same thing with configuration or even basic management of the hardware.

    However this way is worth it when there are many similar devices and the flexibility is actually wanted. When you are selling a product then you probably want to limit ways how it can be 'broken' by your customers or 3rd parties (=applications). And when you are targeting end users who are not developers then any such flexibility may backfire or is simply not appreciated.

    So there are different goals. The way other watches are currently working is IMO fine in principle. The bigger issue is focus, if you are doing it for fun as a hobby in spare time then it is not so polished. Also there is no reliable long term source of these watches so stuff gets outdated and abandoned. Also in my case I see the issue that most of these watches are fun for tinkering but I would actually not like to wear them daily so one less reason for polishing :-) I like ones with always on screen, preferably small light so that's Q3/Bangle 2. The only other watch I liked and used to wear is DK08 and I can imagine wearing G5 too (even if it is a bit bigger).

    i think its worth a look into how it might be done. That's why i'm trying to make a little test bed and play around with it.

    That's great!

About

Avatar for fanoush @fanoush started