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.

[JonW]

Added a deeper menu and a 1000pt temperature logger with an auto-ranging, auto-decimating 10hr circular buffer, plus simple min, max, and ave tracking; I can track and display changes to a fraction of a degree and larger excursions with the auto-range feature.  Added a memory clear and dump to Uart, too, so I can get CSV stats for match-time statistics.  I log the catch rate by time, as this is quite important at the competition level.  87% RAM usage but only 27k Flash, and there is 8k of splash screens. No compilation anomalies in the compiler at all.

 Loving this display and getting back to using Positron vs C

Did a nice fish Glyph and designed a new case, plus added a font table. You can clearly see ghosting with a partial 600ms refresh and a full 2s refresh. 

[JonW]

Here's the latest code.

[JonW]

So now some have seen the code, which 100 percent works in hardware, you maybe shocked to learn that Ai wrote it all.

I drafted the spec and uploaded the PPI, compiler manual, datasheet and the schematic and I worked through it in stages testing and building but it did write all of the code, I didn't type anything into the compiler, just fed back the errors and tested the code.

[Frizie]

AI makes the code cleaner than most people

[John Lawton]

I drafted the spec and uploaded the PPI, compiler manual, datasheet and the schematic

That's amazing, which AI engine did you use?

What format was the schematic in, does it read CAD files directly?

Why the PPI, was that information for the micro concerned?

John

[JonW]

Hi John

I use the Pro Plus version of Claude; it's about £90 a month. I use it a lot for data analysis and document preparation, so I need to keep sessions long and very in-depth.  The PPI ( Positron PPI, not microchip one) was put there so it would know the register names for the device; this greatly reduces the errors at the start of the learning process. After that, I train the LLM by providing example code (usually Les code), providing a text-based template, forcing it to check its own work and running some of the more complex procedures through a Python compiler that it has built (fairly basic).  It has done some things differently from the way others may lay it out, but it compiles with very few mistakes. Most of the mistakes are due to its extensive knowledge of C, and it tries to code in the same way using Positron. The whole temperature log display and secondary menu system took about 6 minutes for it to complete, and it worked first time.  I did get it to write some Python scripts to emulate the eInk display so it could render the backgrounds and compile the full splash screen into hex, but once it had done that, it didn't need the script at all.  I have been using this level of Claude for about 3 years, and the biggest benefit is the projects and the memory.  I have used it to write a lot of C code on the RP2354 and on some ST devices, and it remembers how I like code written and applies the same logic.  This is the major difference from paid versions; they are 1000s of times more efficient. 

A few months back, I had it write a USBTMC (test and measurement) class, along with a GPIB SCPI parser, and then on to a WZ5500 IC, this was all from scratch, not using libraries as they are bloated as hell. It managed to squeeze it all into 70kB!!  I may market it, so I used the new RP2354A with 2mb onboard flash die, which is secure so code can't be ripped, but you can update using an encrypted binary file. It wrote each portion separately, and I had it write complex Python scripts that pushed each module to the limit.  This was then compiled to a single binary for a small product that appears as a USB-TMC class, where you can send standard SCPI commands and some proprietary commands for IP addressing and debugging.  The other side uses the Wiznet chip that connects to the instrument; this side emulates a networked |GPIB class and keeps the connection live.  The Gpib parser then passes and converts the SCPI commands as a bridge.  All in all, you get a USB-to-Ethernet bridge that doesn't require network privileges, so it can run a networked kit in defence-type scenarios where networks are locked, and you have full control using basic Python, LabVIEW, or HP VEE.  Great for any older software that doesn't include networking.

I have taken this one step further and done a USB-to-legacy, fully isolated GPIB adaptor for harsh environments, having 3000V isolation on every pin, including the 5V.  This is particularly important in harsh test environments, as the kit and DUT can float at mains and above voltages.  This doesn't even exist in any NI or Agilent adapters and costs pennies.

The schematic was in PDF format; it can be read and used to produce a pinout spec based on the datasheet.  This is really useful, as it will cross-reference the PPI on the chip with the hardware, ensuring it can theoretically work before the layout is done. 

It proves that AI is much more capable than most realise.  Don't get me wrong, it's not perfect, but it's extremely proficient when forced to build in a small modular way.  I treat it as a very competent junior engineer, not that I have ever met one that can code like that, but it can't be 100 per cent trusted, and you need to fully stress the code with test scripts.  Adding a debug UART is always necessary to verify procedures.  I also captured the SPI data and fed it back in to optimise the timing and battery life.

[John Lawton]

Hi Jon,

thank you for taking the time to give such a detailed reply. It's really impressive what you are able to do using Claude and £60 is a lot cheaper than employing an human engineer to do those tasks.

I'm currently looking at a project using an offline Voice Assistant, which it looks like will require a local AI server for best effect. A year or so ago I wouldn't have considered it, but the tech is moving so fast these days.

John