Thanks everyone! Sorry for the delay replying - thanks for the really detailed responses @user156811!
Absolutely no hard feeling from my side at all - I really appreciate what you're attempting, I just feel bad I'm not so convinced by what's there now :)
You'd mentioned splitting out the barometer code earlier. Did you ever look at that? I think despite it seeming easy, perhaps the backlight code is integrated into enough stuff that actually splitting it out nicely ends up being problematic, and the barometer might be more straightforward.
I like my code to fit under that 100 line limit so i don't need to scroll to much
Do you mean the files themselves, or just functions?
For me VS Code's Ctrl-click -> definition doesn't work very reliably outside of the current file (possibly because of all the ifdefs! Eclipse didn't handle it well either), and so when I end up drilling down multiple function calls which are in different files, it makes it a bit more tricky to follow through smoothly.
There's probably a good middle ground between all-out abstraction and the current insanity that is jswrap_bangle.c though
Do you want it to be an OS like linux to be run on am almost unlimited range of hardware?
It's a good point - and I think realistically it's somewhere inbetween. Ideally as flexible as we can get without introducing much extra code/memory usage because of the abstraction.
Some of the nRF52 builds are very tight - we're now at a point where even something like this fix pushes the code size up enough that the firmware doesn't fit on Puck.js devices without changes!
Another consideration is it's not just Bangle.js that has sensors (Puck.js/Microbit/etc have them too) and in an ideal world we'd be able to reduce duplication there too - but I think possibly that one's just a step too far for the moment.
splitting the big file into more smaller ones (still with all the ifdef spaghetti) could be useful. something like jswrap_banglejs_display|touch|accel|hr|cĀompass|gps|UI|... so that it s not so hug
Yes, I think that could be a good call - maybe a good starting point on the road to making things easier for contributors?
it is already too hard to understand so one more ifdef won't change anything
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.
Thanks everyone! Sorry for the delay replying - thanks for the really detailed responses @user156811!
Absolutely no hard feeling from my side at all - I really appreciate what you're attempting, I just feel bad I'm not so convinced by what's there now :)
You'd mentioned splitting out the barometer code earlier. Did you ever look at that? I think despite it seeming easy, perhaps the backlight code is integrated into enough stuff that actually splitting it out nicely ends up being problematic, and the barometer might be more straightforward.
Do you mean the files themselves, or just functions?
For me VS Code's Ctrl-click -> definition doesn't work very reliably outside of the current file (possibly because of all the ifdefs! Eclipse didn't handle it well either), and so when I end up drilling down multiple function calls which are in different files, it makes it a bit more tricky to follow through smoothly.
There's probably a good middle ground between all-out abstraction and the current insanity that is
jswrap_bangle.c
thoughIt's a good point - and I think realistically it's somewhere inbetween. Ideally as flexible as we can get without introducing much extra code/memory usage because of the abstraction.
Some of the nRF52 builds are very tight - we're now at a point where even something like this fix pushes the code size up enough that the firmware doesn't fit on Puck.js devices without changes!
Another consideration is it's not just Bangle.js that has sensors (Puck.js/Microbit/etc have them too) and in an ideal world we'd be able to reduce duplication there too - but I think possibly that one's just a step too far for the moment.
Yes, I think that could be a good call - maybe a good starting point on the road to making things easier for contributors?
exactly :)