-
• #27
Picos via... Tindie...
...so it was one if the first kickstarter batches that had 'physically' broken corners... for a great deal with no issues though... and your's is looking pretty good... from what I can tell from the pic.
always need to send the complete display data
This puts additional stress on the memory of Espruino... On the other hand, it is well supported by the Graphics object... and constraints usage to static display (not much interactive ui flavor).
May be later model will come up with a partial refresh... because that would be cool...
-
• #28
Great work!
I've always wanted to use this kind of display ever since the Kindle came out.
A bit disappointed on the lower end of it's temperature range.You might use this module to store the fonts in EEROM on the chip.
http://www.espruino.com/FlashEEPROM
Some code examples using arrays are discussed here.
http://forum.espruino.com/conversations/292062/ -
• #29
Looks great! If you're happy to play around in C, another option might be to add antialiasing to the existing Graphics library? You could then use the vector fonts?
-
• #30
This puts additional stress on the memory of Espruino...
as in problems with size or problems with overall usage (frequency of read/write processes)?
A bit disappointed on the lower end of it's temperature range.
according to http://www.pervasivedisplays.com/FAQRetrieve.aspx?ID=43359 :
The storage temperature range for E Ink’s newest e-paper film is now
at -25℃ to 70 ℃.
another option might be to add antialiasing to the existing Graphics
library? You could then use the vector fonts?hmm i am not sure that would be a good move, if we add anti-aliasing (4 colours or 16? just in time calculations?) it will be bigger and afaik nobody asked for anti aliasing until now
what i am after is a better documentation for creating own fonts (in the works) and maybe one additional bitmap font with a greater size
-
• #31
Well, it could antialias in whatever the bit depth is - it wouldn't actually be noticeably slower when working off arraybuffer graphics. It's not a big deal but I thought that was one of the reasons you wanted the custom font (>1 bit colour?).
To create your own font, you could use this and an image containing the characters in a grid: https://github.com/espruino/Espruino/blob/master/scripts/create_custom_font.js
The process isn't well documented, but basically you have one array of bytes which is the widths, and the other array is just a series of 1 bit bitmaps one after the other (not aligned)
-
• #32
I am trying to get this example working the espruino WiFi board - has anyone had any luck?
-
• #33
There shouldn't be any big differences - you've got all the wiring correct?
The only gotcha with that example is that you have to type
save()
on the left-hand side after uploading to save the code into flash memory and call theinit
event. (or you can doE.emit('init')
) if you don't want to do that. -
• #34
N/M - got it working :)
PINS are...
// run following code onInit E.on('init', function() { // SPI configuration var spi = SPI1; spi.setup({ mosi: B5, sck: B3 }); // create display instance var display = require('SSD1606').connect({ displayType: 'GDE021A1', spi : spi, cs1Pin : B6, dcPin : B7, resetPin : A5, busyPin : A4, bs1Pin : A6, // optional, but if not provided, you need to set the correct SPI mode 4-wire by yourself //powerPin : B9 // optional, just do not use the on() or off() function if you do not provide it }); // activate the power to run the display, just a comfort function, // you can control the power by yourself as well display.hwReset(function(){ display.init( function(err){ console.log(err); // (optional) fill the internal buffer for all pixels with color white, // without this the default color will be black display.g.clear(0xFF); // not optional - rotate the display x and y coordinates 90 degrees to the right display.g.setRotation(1); // from here it shows the normal usage // set color black for subsequent uses display.g.setColor(0x00); // set fontsize, see Graphics and Fonts modules for further options display.g.setFontVector(20); display.g.drawString('Hello World!', 22, 22); // from here it shows the needed part // (needed) copy internal buffer to display buffer display.g.flip(); // run the display update display.refreshScreen(function(err){ // do whatever you like here, e.g. turn it off when the update is done // again just a comfort function display.off(); }); }, // clearScreenColor is optional, but prevents e-paper ghosting // shadow of an image may be visible after refreshing (only) parts of the screen { clearScreenColor: 0x00 } ); }); });
-
• #35
i couldn't work further until now - we got a new family member - a daughter :-)
i would like to take a look into
If you're happy to play around in C, another option might be to add
antialiasing to the existing Graphics library? You could then use the
vector fonts?after some hours of Google "research" i did not found resources to start into programming (or better understanding) anti-aliased vector fonts
do you have any hints where to start?
-
• #36
Congratulations!
On Espruino the fonts are just stored as polygons, and are rendered with code like this: https://github.com/espruino/Espruino/blob/master/libs/graphics/graphics.c#L394
Basically you'd want to modify
graphicsFillPoly
in that same file to antialias the edges. You should be able to google some polygon algorithms, but right now it:- 'sketches' out the polygon and finds its minimum and maximum X values for each line
- fills each scan line in turn
What you'd need to do is store the minimum and maximum values fractionally (maybe just by multiplying by 16), and then when you went to draw the scan line, you'd draw the points you needed to the beginning and end in the correct colour. In fact you might want to make sure the polygon fill algorithm take arguments of 16x size as well.
The gotcha is that at the moment Espruino isn't aware of colour at all - it just takes a number and copies it into the next pixel so it doesn't know what R,G and B are. Since you only care about greyscale you could just treat the colour as a number though.
Having said all that, your display is 72x172 pixels right? It might be easier to just use a 1 bit graphics buffer of twice that size in each direction, and to then scale it down by half - making each 2x2 square into single 2 bit pixel.
You could do that with JS initially and see what it looks like. You could probably get it relatively quick using some hacky binary arithmetic to work on groups of pixels at once - or you could look at adding some convenience function in C that would take an ArrayBuffer and then squish it down in 2D.
- 'sketches' out the polygon and finds its minimum and maximum X values for each line
-
• #37
big thanks for the hints
-
• #38
No problem - to be honest the double-size image is probably going to provide you with the best image quality, and it'll be a bit easier too.
technically you always need to send the complete display data (3096 bytes for GDE021A1) (see Page 35 of GDE021A1 specification
afaik when you take the power off the internal ram looses all data, maybe you could work without powering off (using deep sleep and SW reset or no reset at all)
if you combine that with an own driving circuit which provides the I2C connection from the controller you can even read out the ram
for me it is not worth the hassle... but i saw a circular wearable e-paper which looks perfect for an own Espruino low power smartwatch, maybe i try to create my own driving circuit
i got my Picos via Gordons Tindie storefront :-)