Unfortunately LSB in SPI is for the bit order, not the byte order. I guess there should really be an option when initialising Graphics, but for now you could actually cheat and set the colour that you want right at the start...
setColor takes either r,g,b or the actual bit representation of the colour, and getColor returns the bit representation. You could do setColor/getColor on the first graphics context, and could then flip the bytes around for the next one (the first context would have to be 16 bit too).
LCD.drawStringBuffered = function(str, x, y, fontSize, r, g, b){
//Create a dummy Graphics object to get size of string in fontSize
var g = Graphics.createArrayBuffer(1, 1, 16);
g.setColor(r,g,b);
var col = g.getColor();
col = ((col>>8)&0xFF) | ((col<<8)&0xFF00); // flip bytes
//....
g = Graphics.createArrayBuffer(width, height, 16);
g.setColor(col);
// ...
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 - that's a really neat idea!
Unfortunately LSB in SPI is for the bit order, not the byte order. I guess there should really be an option when initialising Graphics, but for now you could actually cheat and set the colour that you want right at the start...
setColor
takes eitherr,g,b
or the actual bit representation of the colour, and getColor returns the bit representation. You could do setColor/getColor on the first graphics context, and could then flip the bytes around for the next one (the first context would have to be 16 bit too).