esp32 SPI slave in case you need to sniff what the master sends. I'm trying to reverse enginner GxEPD epaper library to make my own object oriented epaper driver component for ESP-IDF
One epaper so far is working but others are not. Even though I'm sending exactly the same commands using ESP32 as SPI master comtroller. Why not?
Because there is something different. Or because there is a missing command that without it the epaper wont boot up... Thats why I though ok lets try to find a library to flash one ESP32 and let it work as a SPI slave. Then you can hear what commands a working example sends and compare with your non working program to discover what are you doing wrong.
Master | Slave
MOSI MOSI
CLK CLK
SS SS Chip select
DC DC Data command
Busy Busy (Not yet implemented check busy* section)
The epaper expects commands that are sent with both SS and DC low, hi on transfer termination. Data commands are sent turning only SS low (but not DC). At least in the epaper library that I am analysing Slave Select must be turned low to speak with the slave but only DC low signalizes a Command.
The part of the library that does that can be seen here: https://github.com/ZinggJM/GxEPD/blob/master/src/GxIO/GxIO_SPI/GxIO_SPI.cpp#L114
Busy* PIN this is really important when doing a CPU based slave SPI: You don't have the same response time as a native SPI device so there is latency. That's why we are going to add a busy state to this project. The master should send and wait until the Busy pin is low to send again. That way we can have a slow slave that logs without missing precious commands/data in the slave due to slow response.
The goal of this tool is to become a reliable logging tool for driver actions. To be an aid to discover why your own implementation is missing something if you reverse engineer some other library. It is of course not the mission to act as a logic analyzer.
We just want to see which SPI master CMDs and DATA that arrives to a device. It's interesting to hook it into an existing project and see how it interacts with it, like add it to a working epaper circuit, and show what commands make the epaper refresh.
Please do not fork this library unless you want to:
Add a correction
Collaborate with the project in some way
I dislike having many copies of the same project without a clear reason of why they are there. If you want to fork just to do a fork, then do it in iPAS original project.
https://github.com/iPAS/esp32-slave-spi iPAS Espressif ESP32 documentation about SPI