Micro ePaper for Bluz?


#1

Hi,
I am thinking about porting an ePaper library to the Bluz

  • based on Adafruits GFX library
  • extended by SPI communication to the driver IC of an 1.1" ePaper display
  • 148x72px w/ 4GL, requiring 2.6kb frame buffer plus some overhead

Currently the code appears to be somehow blocking (Bluz seems not to connect to gateway anymore once the application is running.

Besides the SPI communication there is one GPIO wire sensing the “busy” state of the ePaper driver IC; and waiting in a loop until the IC is not busy anymore:

 void PL_microEPD::waitForBusyInactive(){
      while (digitalRead(busy) == LOW) {Particle.process();}
 }

Is this loop blocking, or does Particle.process(); handle the communication tasks for the Bluz? If this loop is blocking, maybe someone could guide me to a better approach… e.g. a software interrupt?

Many thanks in advance…


#2

Particle.process() isn’t currently supported on bluz. I have opened an issue so we can add support for this in a future release: https://github.com/bluzDK/bluzDK-firmware/issues/41

I haven’t looked at the library, but I would imagine that line should only block for short periods. Or is the library always blocking?

Some libraries certainly require tweaks to work with bluz, but most should be relatively straight forward. Does the library work? Are you able to draw to the screen?

An interrupt here would certainly fix the issue. I am not sure when waitForBusyInactive() would be called/used, but you could instead set an interrupt on the pin and communicate once it triggers.

I will try and run the library at some point to see where the issue could be, though I don’t have an ePaper screen to actually verify it is working.


#3

The code blocks around 700ms every time a page update is triggered.The remaining periodes during initialisation & data transfer should be much shorter.

Currently the screen does not update … will try to find out more during the week-end…

If you are interested I could send you a hand-soldered prototype for testing :wink:


#4

Is this your personal project? I like the docs format, looks familiar! https://robpo.github.io/Paperino/

I would be happy to test out a prototype with bluz, is the device currently for sale? Let me know


#5

Jepp this is my personal project. After having seen your clean Bluz documentation I started using MKdocs too for descriptions; its really nice… :wink:

There will be a campaign at crowdsupply for the device in hopefully four weeks. I have a hand-soldered, not nice looking but electrically working prototype here and will send it to you on monday.

I would be really happy if we could get Bluz & ePaper to run together… I believe its a useful combination…


#6

What is the MFG’ product number of the 1.1" EPD you are using and who is the manufacturer. My reason for asking is that there are several generations and sizes of LCDs out there with different technologies requiring separate external Timing Controller from the LCD. However it is only the latest generation “CS” series (E2215CS062) that uses Internal Timing Controller and fewer contacts and a simpler ribbon cable to connect. We were able to use Particle’s P1 module to drive the old technology and planned on using Bluz as well, when we stopped to redirect to the new technology. I hope this is helpful. We can drive graphics and text with the 2.15" new LCD with USB direct connection and would like to use Bluz to update content wirelessly.


#7

@eric As an update I started looking into this but so far without beeing able to update the display.
One problem seems to fly around the earlier mentioned loop which is called after initialisation of the driver IC… after complete power cycling I can run a minimal script at least without failure to the end- but after pushing the reset button or after flashing, the script remains always eternally in the loop and I cannot connect to the bluz anymore. Hmm, can we learn something from this? By the way, to flash new code once its running eternally in the loop I then do a factory reset to see the device back online in the web IDE… is there eventually a better way of doing this (since it always takes some minutes to upgrade to newest firmware release)? :wink:

A second topic is related around the SPI connection. My library so far is based on Photons SPI1 pins (D2…D4) for communication… the bluz documentation refers to SPI pins on A3…A5; is it generally possible to to use the SPI1 pins as well?

As a third topic, I have the feeling that this (not very important) function causes a hang-up

void PL_microEPD::invertDisplay() {
    for (int i=0; i<arraySize(buffer); i++) {
         buffer[i] = ~buffer[i];
    }
SPI.transfer(buffer, NULL, arraySize(buffer), NULL);
}

#8

@DAB The 1.1" EPD is from Plastic Logic (the company where I am working at), pls see the link for more informations. The used driver IC UC8156 does all the timing internally too and just needs an external power circuit to generate the high voltages. Communication is based on 4wire SPI and two further pins for reset’ing the IC and for sensing the “busy”-state. These displays support four greylevels and partial screen updates, which I think is not possible with the small EPDs from Pervasive Displays. If you need more details just let me know…


#9

There is an easier way then factory resetting, you can try out the new bootloader we have available. This exposes the safe-mode feature that is on the Photon, you can release the button when it starts flashing magenta as you boot the board and it will wipe out the user app and force safe mode. Clears your code without modifying the system version. We are hoping to broadly roll this out in the future, but we have it as a beta feature for now: Beta Bootloader Testers Wanted

SPI1 isn’t available on bluz. There are only two SPI peripherals and one is reserved for the SPI Flash on-board. Technically the SPI pins can be re-mapped, but this isn’t available in the user app at the moment.

I can try out some of the libraries on bluz to see if there is an issue. Once I get the sample board, I can try and get it working as well.


#10

Thank you! Will try the new bootloader next time.

Meanwhile I could fix the earlier mentioned problem around the IC initialisation and bluz can now boot reliably with the ePaper;-) And after changing the code to SPI (from SPI1) and adjusting the clock speed it works well for the first time!!! :wink:

https://www.youtube.com/watch?v=P-RwnWJaSL8


#11

Thanks for sending the sample, I got it working on my end too. The board is awesome!


#12

Great! If there is interest, we could re-route the shield to use the SPI0 pins. This would enable to use Bluz via plug and play without wiring, similar to Photon+Electron…


#13

I think it would be great to have the shield work with the SPI pins on bluz. We can also make them configurable from our end as well. Is there a reason the SPI1 pins were chosen?


#14

There was no real reason for choosing SPI1 pins so it is no problem to change them to SPI0 for the next PCB release (would make the lib code cleaner). Bluz works with the battery shield too, right? I’d then envisage to use such stackable headers to put the epaper shield on top of the battery shield (the other way round half of the screen would be covered). Will try that soemwhere this week and let you know…


#15

Just to let you know that the campaign at crowdsupply for a bluz-compatible micro epaper shield is out there since today: https://t.co/mQRugD7rZ1