Waveshare e-paper displays with SPI

[ZinggJM]

Warning: series resistors may not be enough for some e-paper displays to work with 5V Arduinos!

Usually I test for AVR Arduinos with a 3.3V Arduino Pro Mini. But recently I made a proto board for Arduino UNO with series resistors of 4k7 ohms on data lines. I successfully used it with a Nucleo-64 board.

Now I tried to use it with Arduino UNO and a 4.2" b/w board from Waveshare. This did not work, no reaction on the display. The test with the 1.54" b/w board was successful.

I measured the voltage on the 3.3V supply pin on the Arduino that should be supplied from the series regulator on the Arduino board, the resulting voltage was about 4.4V.

The series resistors are enough to back-feed through the protection diodes of the controller to the display, as long as the display is not powered up by command ("high voltage" +-15V generation inactive).
This because the Arduino UNO has no load on the 3.3V supply. The resulting 4.4V is just above the maximum spec of the e-paper controller.

A 2k load on the 3.3V supply reduced the voltage to ~3.4V, but the 4.2" display still did not work.

With the 2k load the 1.54" also no longer works correctly.

I then added 10k pull-down resistors to the data lines, resulting in 2/3 voltage dividers.
With this the 4.2" display worked, except for the partial update test part of the GxEPD2_Example.
The reason was the RST signal was not low enough to wake up the controller. There may be a pull-up resistor on that line, I have not yet measured. Measured: has no pull-up.Using a 4k7 pull-down on RST instead of the 10k fixed this. Reason unclear, 2k load?

My recommendation to use at least series resistors with 5V Arduinos is not sufficient!

Additions 23.11.2018:

For 1.54" b/w I recommend to add a 1k resistor between 3.3V and ground, to protect against too high supply voltage caused by back-feed through the 4.7 series resistors on the data lines, and a 10k resistor to gnd on the CLK line to the display. This combination worked on my test, see picture.

For the 4.2" b/w an additional 10k resistor from DIN to gnd made it work.

For Arduino MEGA I had to add another 10k to CS to make it work with the 4.2" b/w

Conclusion: for reliable operation voltage dividers should be used on all input data lines to the e-paper for 5V Arduinos, e.g. 4k7 to 10k to get 3.3V levels, or true level converters.

[silicagel]

I am sorry that I have to ask what is a no doubt a stupid question, if its any consolation I expect that the answer is simple. I am using a 1.54 inch e-Paper Module and have this working on a UNO, but now am trying to hook it up to a MEGA2560 and I am unsure of the mappings to use. Suggested is  BUSY -> 7, RST -> 9, DC -> 8, C S-> 10, CLK -> 13, DIN -> 11 but I also read somewhere that on a MEGA2560 that MOSI -> 51,  MISO -> 50,   SCK -> 52,  SS -> 53.

when I use
GxIO_Class io(SPI, /*CS=*/ 53, /*DC=*/ 50, /*RST=*/ 9);
GxEPD_Class display(io /*RST=9*/ /*BUSY=7*/);

I have no success.

[ZinggJM]

Use level converters or voltage dividers on data lines with 5V Arduino. Never connect directly to 5V data or supply pins!

You need to connect to the correct pins for SCK and MOSI on Arduino MEGA. All other pins can be chosen freely, but the pins must correspond to the values in the constructors, change accordingly.

BTW, you can search for "MEGA e-paper" in the forum, to get more answers, e.g. this post.

[teo8976]

Hey ZinggJM,

In your examples from GxEPD2_32:

Code: [Select]

#if defined (ESP8266)
// select one and adapt to your mapping

GxEPD2_32_BW display(GxEPD2::GDEW042T2, /*CS=D8*/ SS, /*DC=D3*/ 0, /*RST=D4*/ 2, /*BUSY=D2*/ 4);

Are the /*...*/ comments wrong, i.e. inconsistent with the actual mappings?

In particular:

Code: [Select]


/*RST=D4*/ 2,
/*BUSY=D2*/ 4

That made me think that perhaps, counterintuitively, 2 was D4 and 4 was D2, but according to this:
https://learn.sparkfun.com/tutorials/esp8266-thing-development-board-hookup-guide/using-the-esp8266-in-arduino
2 is D2 and 4 is D4.

Did you change the mappings and not update the comments, or are the namings in Sparkfun docs wrong, or am I missing something?

[ZinggJM]

@teo8976,

I first needed to check if SparkFun ESP8266 Thing is officially supported by the ESP8266 package in:

C:\Users\xxx\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.4.2\boards.txt

and found the entry for it, e.g.

Code: [Select]

thing.name=SparkFun ESP8266 Thing
thing.build.board=ESP8266_THING
thing.build.variant=thing

Then I had to check for pin mapping for this "thing":
C:\Users\xxx\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.4.2\variants\thing\pins_arduino.h

Code: [Select]

#ifndef Pins_Arduino_h
#define Pins_Arduino_h

#define PIN_WIRE_SDA (2)
#define PIN_WIRE_SCL (14)

static const uint8_t SDA = PIN_WIRE_SDA;
static const uint8_t SCL = PIN_WIRE_SCL;

#define LED_BUILTIN 5

#include "../generic/common.h"

#endif /* Pins_Arduino_h */


It just includes common.h and does not define any Dx names like for NodeMCU or LOLIN(Wemos) D1 mini:

C:\Users\xxx\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.4.2\variants\d1_mini\pins_arduino.h:

Code: [Select]

#ifndef Pins_Arduino_h
#define Pins_Arduino_h

#define PIN_WIRE_SDA (4)
#define PIN_WIRE_SCL (5)

static const uint8_t SDA = PIN_WIRE_SDA;
static const uint8_t SCL = PIN_WIRE_SCL;

#define LED_BUILTIN 2

static const uint8_t D0   = 16;
static const uint8_t D1   = 5;
static const uint8_t D2   = 4;
static const uint8_t D3   = 0;
static const uint8_t D4   = 2;
static const uint8_t D5   = 14;
static const uint8_t D6   = 12;
static const uint8_t D7   = 13;
static const uint8_t D8   = 15;
static const uint8_t RX   = 3;
static const uint8_t TX   = 1;

#include "../generic/common.h"

#endif /* Pins_Arduino_h */


So they should not mention Dx names in their documentation, nor use it for any inking, as these are not defined.

This should answer your question.

[4lexO]

Hello ZinggJM,

I successfully setup the E-Paper and I can't find a library to get more characters supported like accents : "éèà" or chinese characters.

Are these characters supported ? If not, is there a way to add libraries ?

Thanks,
Alex

[ZinggJM]

Hi Alex,

Its always helpful if you mention the library you use, so I do not need to look for your previous posts.

Please take a look at GxEPD2_U8G2_Fonts_Example.ino

[silicagel]

Use level converters or voltage dividers on data lines with 5V Arduino. Never connect directly to 5V data or supply pins!

You need to connect to the correct pins for SCK and MOSI on Arduino MEGA. All other pins can be chosen freely, but the pins must correspond to the values in the constructors, change accordingly.

BTW, you can search for "MEGA e-paper" in the forum, to get more answers, e.g. this post.

Thank you for your reply. I have no idea how interpret your text in red. I am connecting to the 3.3V on the Mega2560 and am using waveshare 1.54inch e-Paper Module, which I assumed would deal with this issue? In case this is the problem, can you give a link to where this might be explained. In case its an error in my code, I have pasted in a reduced example of PagedDisplayForSmallRam which I am using.

Code: [Select]


#include <GxEPD.h>
#include <GxGDEP015OC1/GxGDEP015OC1.h>    // 1.54" b/w
#include <GxIO/GxIO_SPI/GxIO_SPI.h>
#include <GxIO/GxIO.h>
#include <Fonts/FreeMonoBold9pt7b.h>
#include GxEPD_BitmapExamples

GxIO_Class io(SPI, 53, 50, 9);
GxEPD_Class display(io,9,7);

#define DEMO_DELAY 10

void setup(void)
{
  Serial.begin(115200);
  Serial.println();
  Serial.println("setup");
  display.init(115200); // enable diagnostic output on Serial
  Serial.println("setup done");
  
}

void loop()
{
  display.drawExampleBitmap(BitmapExample1, sizeof(BitmapExample1));
  delay(DEMO_DELAY * 1000);
  display.fillScreen(GxEPD_WHITE);
  delay(DEMO_DELAY * 1000);
}




[ZinggJM]

Read this post please.

The back-feed through the protection diodes causes distortions of the SPI communication.

[Narceen]

Hello,

i didnt know if this Question was answered before but after i updated GxEPD Lib to 3.0.2 it stop working.
Before all working fine.

Got this Serial Output

command 0x3b : 10000522
Busy Timeout!
command 0x11 : 10000504
Busy Timeout!
command 0x44 : 10000506
Busy Timeout!
command 0x45 : 10000535

I dont change anything than updating the Lib from 2.6

EDIT: With Version 3.0 it working fine

[ZinggJM]

Hello Narceen,

please tell me your configuration, e-paper display used and processor board used.

And in case of AVR processor the wiring used.

I don't see how the change to SPI with transaction can cause your issue, but with details I can check.

[Narceen]

Thx for the fast reply.

I use an STM32F103CB board with the standard wiring and an 1.54 inch display.

[ZinggJM]

Ok, I will check this tomorrow. You could tell me the version of your STM32 package, and where it comes from.

[Narceen]

Arduino_STM32 with Version 2018.9.15

[teo8976]

Hi @ZinggJM

I'm trying a GoodDisplay DESTM32-S2 with the raw WaveShare displays, instead of the controller ("hat") that comes with the display. It seems to solve the boot issues.

However I have a different issue:
I systematically get busy timeouts on almost all operations, though not on powerOff (not sure whether powerOff waits on Busy).

For example:

Code: [Select]


Busy Timeout!
POWER : 40000151
Busy Timeout!
_PowerOn : 40000862
(...)
Busy Timeout!
_Update_Full : 40000799
_PowerOff : 40044


If I just wait, everything works: I succesfully download an image and stream it to the display (using this).
There's no timeout while streaming the pixel bytes, but I'm not sure whether the busy line is being checked there.


I am using the PIN mappings from the examples:

Code: [Select]


// works with WS's hat, systematic busy timeouts with the DESTM32-S2
GxEPD2_32_3C display(GxEPD2::GDEW075Z09,  /*CS*/ SS, /*DC=D3*/ 0, /*RST*/ 2, /*BUSY*/ 4);
Of course the physical wirings are done accordingly.


I had an IDENTICAL issue (as far as observable behavior is concerned) with the original WaveShare hat when trying your suggested alternative mappings (to try and fix the boot issue, which it didn't):

Code: [Select]


// systematic busy timeouts with WS's hat
GxEPD2_32_3C display(GxEPD2::GDEW075Z09,  /*CS*/ 4, /*DC=D3*/ 0, /*RST*/ 2, /*BUSY*/ 12);
(of course changing the physical wirings accordingly)

I assumed MISO couldn't really be used as you suggested, because of interferences with SPI internal workings. But now I get the same issue on the DESTM32-S2 with the original mappings.

Any idea?