Again have you tried any baby steps I mentioned in many posts?
Example does the SPI work at all?
How about running a simple SPI app that does something like:
Code:
#define PIN_SCK 18
#define PIN_MOSI 23
#define PIN_DC 5
#define PIN_CS 22
#define FILL_CHAR 0xfe
uint32_t clockRateSetting = 8000000;
#define DBGSerial Serial
void setup()
{
while (!DBGSerial && millis() < 3000) ;
DBGSerial.begin(115200);
delay(100);
DBGSerial.println("Start setup");
pinMode(PIN_CS, OUTPUT);
digitalWrite(PIN_CS, HIGH);
DBGSerial.println("Before pinMode DC"); Serial.flush();
pinMode(PIN_DC, OUTPUT);
DBGSerial.println("Before SPI Begin"); Serial.flush();
SPI.begin();
DBGSerial.println("End Setup"); Serial.flush();
uint8_t screenmemory[33];
uint8_t retbuf[33];
void display_transfer_buf_verify(void)
{
uint8_t i;
DBGSerial.print("Verify transfer(MOSI-MISO: ");
SPI.beginTransaction(SPISettings(clockRateSetting, MSBFIRST, SPI_MODE0));
digitalWrite(PIN_CS, LOW);
memset(retbuf, FILL_CHAR, sizeof(retbuf)); // init to some bogus value...
SPI.transfer(screenmemory, retbuf, sizeof(retbuf) - 1);
digitalWrite(PIN_CS_HIGH);
SPI.endTransaction();
for (i = 0; i < sizeof(retbuf) - 1; i++) {
if (screenmemory[i] != retbuf[i]) {
DBGSerial.print("Mismatch found index: ");
DBGSerial.print(i, DEC);
DBGSerial.print(" W: ");
DBGSerial.print(screenmemory[1], HEX);
DBGSerial.print(" R: ");
DBGSerial.println(retbuf[i], HEX);
return;
}
}
// Check last value still equal our fill character
if (retbuf[sizeof(retbuf) - 1] != FILL_CHAR) {
DBGSerial.print("End byte change: ");
DBGSerial.println(retbuf[sizeof(retbuf) - 1], HEX);
}
else {
DBGSerial.println("Succeeded");
}
delay(2000); // Wait a couple of seconds.
}
Warning, this was cut/paste with edits from test programs... So I may have missed something. But the idea is to try to send a number of bytes using SPI. Now run a jumper wire between MISO and MOSI pin and see if the data bytes get transferred. If so you have a pretty good idea that those pins are working.
Things that would concern me, include: looking at his schematic you see that there is an RGB led on the board, that appears to be connected with pins (16, 17, 18), Will it's use interfere with using pin 18 as the SCK pin for SPI? Or is it like Arduino boards who have the LED pin on 13?
So again with another baby step am I correct that that these three pins do RGB LED? I would maybe hack up a program like:
Code:
uint8_t counter = 0;
void setup() {
// maybe do some Serial.... if needed
pinMode(16, OUTPUT);
pinMode(17, OUTPUT);
pinMode(18, OUTPUT);
}
void loop() {
counter++;
if (counter == 8)
counter = 0;
digitalWrite(16, (counter & 1) ? HIGH : LOW);
digitalWrite(17, (counter & 2) ? HIGH : LOW);
digitalWrite(18, (counter & 4) ? HIGH : LOW);
delay(250);
}
Does the LED turn on and change colors every .25 seconds?
Again if it were me I would use a Logic Analyzer to see all of the signals... If I did not have one, I would hack up a test harness..
Example use a Teensy, ( I would start with the one I had with the most memory. and maybe try simple test app, that maybe simply checks for one or more pins changing state. Then connect the teensy up to the ESP32 with ground wire plus connect the several pins that I think are SPI between them.
Then on Teensy, maybe do things like: digitalRead each of the pins between the two and if the state of a pin changes, print that a state changed... You can do that for each of the pins, to know that there is at least some state changing on the ESP32.
If at appears you can get those to talk, then maybe setup a trigger pin between the two boards, maybe use CS pin. and when it changes state, run the teensy in a quick loop, reading the logical, CS/DC/SCK/MISO/MOSI pins and try to capture for some brief amount of time or until you fill so much memory.
Then you can do some rudimentary printing of when you see that any of the states changed... To see if it logically makes sense...
And/or you might be able to setup to use the Teensy Logic Analyzer program to do all of this...
But again Baby steps!
