Waveshare Eink

[JonW]

Sent out a simple Dev board for Eink using the 18F27Q43, added an encoder and an External NTC and USB.  The displays are really nice but slow, just working on the partial refresh, and it still takes around 500ms with minimal ghosting.  The trick is to update the registers and then partial refresh after a short no-use delay then after say 1 minute do a full refresh to erase the ghosting. Still a lot to learn

Compiler working solid on the 27Q43

[CPR]

Lovely display! Do you have any plans to sell the boards?

[JonW]

Assembled boards?  I need to change the connector mating as the Waveshare was fitted with a different connector than I expected.

Updated a bitmap splash screen and battery self-measurement.  Well cool displays

[top204]

Very nice Jon.

Is the code commercial, or can it be shared on the forum?

Regards
Les

[JonW]

Thanks Les

It's personal at the moment, but a commercial version may be on the cards; I need to fix the connector in this dev version, then release the schematics, layout, and the procs on the forum.  I've simplified the current render to rectangles (filled or not) rather than a full font table to minimise the coding (hence the retro blocky text), but have included an arbitrary flash frame buffer and have managed to get partial and full refreshes working well.  The current design uses a 1.024V reference for the NTC and a USB power switch so the current can be minimised to a very low figure.  The current application should run for 3 years with frequent use on 2 x AAA batteries and remain in standby indefinitely or until the cells degrade. I did consider a DC-DC for LiPo use; however, the 27Q43 and the rest of the circuitry can run to 2.3V, so there is little point really, and the switchers will only add an ICQ drain.  To keep the refresh quick I run at 4M then speed up for processing tasks to 64M.

I did have a bit of trouble with the EC11 and bounce because I omitted caps on the pull-ups (Doh), so I added a global loop tick as a simple time-debounce filter. I'll also fix this.  The board also has a Piezo, 2 LEDs, 4 push buttons, a 1.024 Ref for ADC with shutdown, an EC11 encoder with push, a 32.768 kHz xtal, a TPS22917 USB switch for the display VDD, a CP2102 bus-powered with RTS on CLR for a bootloader and debug to USBC, and an ICSP header. 

If anything else is needed, I may consider adding it to a Positron Version, since the bare boards are super cheap. 

It's currently being built for outdoor use for my match Fishing hobby as a timer, net accumulator and a temp sensor, the commercial ones are all LCD and they are completely useless in full sunlight, these E-ink displays are unreal for that and are super low power.  The commercial ones also have a ton of buttons so I simplified it to a single EC11 with a menu.

Great fun and to date no issues with 27Q43, NCO, Timers, Sleep, Multi speed use, Flash reads, HW Uart, HW SPI, Flash and Table reads, Procs ADC, FVR etc.  Flash write routines and a config menu system today.

 

[JonW]

Also bought a FDM P2S and am trying to get better at enclosure design and running the printer.

[trastikata]

Jon,

if you are re-designing the board, it would be prudent to make space for SO8 SRAM IC, connected to the second hardware SPI module of the MCU, if the first one is used.

Unlike TFT displays, e-paper displays require only 1 bit of SRAM space for B/W and extra 1 bit if Red/Yellow is available. Thus an inexpensive small SRAM chip will suffice and it gives a lot of extra capability.

Let me know if you have some questions, maybe I can help with something if you remember my post here:

https://protoncompiler.com/index.php/topic,3225.msg23843.html#msg23843

I finished the buffer-less rendering for shapes and fonts (quite a lot of thinking there) and now only left is to organize and publish the update on the web site. In 2 weeks I finish current real-life work project and then I will have few weeks free for hobby and stuff.

[JonW]

Im IO maxed out, but i could multiplex with the push buttons and ICSP

[JonW]

working code, unchanged,  Snap of a my single project file. uncut

[JonW]

What ram chip did you use? 

[trastikata]

Hi Jon,

I used 1 Mb SRAM from Microchip but it will depend on screen size and number of colours. If you have only Black/White then it is 1 bit per pixel, if you add a Red/Yellow plane then it is one extra bit per pixel.

Why would it be good to have SRAM - as you already found out, the internal RAM in those e-paper displays is organized in bytes where each bit represent a pixel. So if you draw something in two adjacent bytes (changing pixels/bits) then there is no problem. However drawing in the same RAM byte will effectively erase the previous state of the byte, if there is no record of this byte.

For example your draw a glyph and the font size is 8 bit (pixels). Now you want to add another glyph next to the first (like printing a text) ... you have two cases:
- case one - initial glyph had an absolute position at the beginning of the byte, then the next glyph is the beginning of the next byte - everything works.
- case two - initial glyph starts somewhere in the byte, lets say bit 6 - ok you print it in two neighbouring bytes, now where the second glyph will start? If you start the glyph in the second byte, without knowing what was in the previous byte you will erase part of the previous glyph. If you start the second glyph in the third byte, it and the first glyph will print correctly but the free space will become uneven.

In another situation you might want to overlay text over picture, then printing in whole bytes adds the white space you observe in some demo images over the internet, exactly because of the same problem.

And so on ... small mono-colour displays required very little SRAM and small RAM chips are inexpensive but add quite the possibilities.

In my library everything is done/updated in the SRAM and then using a burst transfer, sent to the e-paper. Given the very slow update times for e-paper displays hundreds of milliseconds to seconds, working in the SRAM and transferring data to the display is few milliseconds only which can't be noticed by the user.

One thing to consider - SRAM is volatile, thus keeping the current screen would require second FLASH memory IC, if needed by design. Before power down or after screen update (depending on design requirements) SRAM can be saved in the FLASH memory, if needed at all.