like that very much (post #3 - missed it while in 'forum's display time window'):
I did not use jswrap_ bangle.c as I found it easier to develop drivers in Espruino.
Why? I't is core to Espruino.
With faster and even lower power hardware (and enough memory), the next step may for many things be left out completely:
I intended to put these into C afterwards but the Espruino driver performance seemed quite useable so I did not bother.
Moving to layout, I see now the same challenges as with the hardware: the abstract / common parts can be integrated where the very specific ones need their own implementation. I had suggested a while ago to have layout eco system to have the ability to 'branch out' because scaling is not a complete solution. In this case of a rectangular vs a square display, it would be nice to have the ability of unique layouts. I understand @Gordon 's reasoning to not get there, because it is not only not in his (current) set of hardware options, but also: Who is willing to build these things in the first place while having only one particular hardware, and who will update / complement the existing applications, etc. Longterm, I though see suitable source structure and build and runtime infrastructure to come to be, since also @Gordon has to respond to the hardware evolution - as he did for his own boards.
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.
@jeffmer,
like that very much (post #3 - missed it while in 'forum's display time window'):
Why? I't is core to Espruino.
With faster and even lower power hardware (and enough memory), the next step may for many things be left out completely:
Moving to layout, I see now the same challenges as with the hardware: the abstract / common parts can be integrated where the very specific ones need their own implementation. I had suggested a while ago to have layout eco system to have the ability to 'branch out' because scaling is not a complete solution. In this case of a rectangular vs a square display, it would be nice to have the ability of unique layouts. I understand @Gordon 's reasoning to not get there, because it is not only not in his (current) set of hardware options, but also: Who is willing to build these things in the first place while having only one particular hardware, and who will update / complement the existing applications, etc. Longterm, I though see suitable source structure and build and runtime infrastructure to come to be, since also @Gordon has to respond to the hardware evolution - as he did for his own boards.