Use of different pins for SPI with GxEPD2

[michaelschnyder]

I wanted to know what the rationale is to default to the HSPI bus, when using the GxEPD2. I see I could easily adjust the Ctor and pass either the Bus-ID or Pins there, which could be passed to the SPI Init.

void GxEPD2_EPD::init(uint32_t serial_diag_bitrate, bool initial, uint16_t reset_duration, bool pulldown_rst_mode, int8_t sck, int8_t miso, int8_t mosi, int8_t ss)
{
/* ... */
SPI.begin(sck, miso, mosi, ss);
}

or alternatively, add an additional overload for init(), which would specify the BusID? If working with the BusId, it would somehow duplicate the code in the SPI::init(), so that might not be preferred.

Why
I do already have a SD card on HSPI and was running into troubles with my two cores on ESP32. Both cores might communicate on the HSPI at the same time, and I would prefer to separate the devices in hardware than having a mutex and making things more complex in the software.

I also saw the class spi_settings, which might have been introduced for a similar reason. Should the configuration of the SPI be there?

I somehow also refer to this: How to use HSPI buses with GxEPD2 library on ESP32 DevkitC v4 - Using Arduino / Displays - Arduino Forum. Conclusion: Can be done, no official support, bc. lack of reasoning I guess

-Michael

[ZinggJM]

@michaelschnyder

I wanted to know what the rationale is to default to the HSPI bus, when using the GxEPD2. I see I could easily adjust the Ctor and pass either the Bus-ID or Pins there, which could be passed to the SPI Init.

Yes, you can. Keep it simple was the design goal when I started GxEPD2.
But you can easily create your own GxEPD2_EPD class for your need.
See also extras/sw_spi/README.MD.

GxEPD is easier to adapt. You could create your own GxIO_SPI class.

Welcome to the forum! I don't like to have to justify my design decisions.
See also How to get the best out of this forum.

Jean-Marc

[michaelschnyder]

Thanks @ZinggJM for your fast feedback and the link, I will have a look into that!

@ZinggJM

I don't like to have to justify my design decisions.

Hope no offence taken :). My request was not for to ask for justification, more on the thoughts process behind so find out how I would extend the library in the best possible way, so others might be able to profit from it too.

I'm currently extending some of the classes and will let you know if there is something valuable coming out of the exercise. I'll publish it at michaelschnyder/GxEPD2 at Add-Support-For-Custom-SPI-Pins (github.com)

[michaelschnyder]

Just FYI @ZinggJM: I made the necessary changes for the BW display driver in the fork michaelschnyder/GxEPD2 at Add-Support-For-Custom-SPI-Pins (github.com).

Quick summary (from the ReadMe)

const int SCRN_BUSY = 26;     // ePaper Busy indicator (SPI MISO aquivalent)
const int SCRN_RSET = 13;     // ePaper Reset switch
const int SCRN_DC   = 12;     // ePaper Data/Command selection
const int SCRN_CS   = 15;     // SPI Channel Chip Selection for ePaper
const int SCRN_SCK  = 14;     // SPI Channel Click
const int SCRN_SDI  = 27;     // SPI Channel MOSI Pin  
const int SCRN_SPI_CHAN = 2;  // HSPI

GxEPD2_DISPLAY_CLASS<GxEPD2_DRIVER_CLASS, MAX_HEIGHT(GxEPD2_DRIVER_CLASS)> display(GxEPD2_DRIVER_CLASS(SCRN_CS, SCRN_DC, SCRN_RSET, SCRN_BUSY));

SPIClass otherSPI(SCRN_SPI_CHAN ); // Default is VSPI, which is probably in use for the SD Card
display.init(SCRN_SCK, SCRN_BUSY, SCRN_SDI, SCRN_CS, SCRN_SPI_CHAN);

Files changed can be seen here: include overloads to specify pins and SPI bus · michaelschnyder/GxEPD2@9f662da (github.com). Summary

• Use SPI instance to communicate instead of SPI so that a SPIClass with different bus Id can be passed in
• Pass in additional PINs to both the Class and Driver and make sure the existing signatures remain intact.
• Tested with and without additional parameters

No expectations here, just wanted to summarize and close this thread. If you have suggestions and remarks it would be appreciated for sure. Also I did not add a PR as I cannot provide the code for all display types because of lack of hardware to test.

-Michael

[kaangoksal]

Can we actually merge @michaelschnyder 's fork or the suggested code in the extras folder (GxEPD2/extras/sw_spi at master · ZinggJM/GxEPD2 · GitHub) into the main branch? I'm using a TTGO T-BEAM V1.1 board, the SPI pins are not exposed, so I have to define my own pins. I believe defining your own SPI pins will be a common use case in future.

I see that the main GxEPD2_EPD.cpp already started differentiating from the one that is provided in extras. In future this can become a maintenance pain / tech debt.

I just tried the instructions posted here: GxEPD2/extras/sw_spi at master · ZinggJM/GxEPD2 · GitHub

it works great!, only downside is you have to have a local fork in your own environment + you need to cherry pick new updates.

Thanks a lot for working on this, let us know if we can support you in any way.