GPS

• Copilot was able to do a lot in this area. Most of my work involved finding the right library to use, finding the right version of that library, and making sure it was properly installed.
• There were some comments in the library source code explaining some nuance to the order in which functions should be called, so I had to refactor to touch that up a bit.
• But for filling in functions like estimating UTC offset or calculating the day of the week, Copilot was quite helpful. It’s most useful when I already have the structure and clear inputs and outputs defined.
• I tested the code by running the code, printing out the number of satellites in view, and printing the time and date received.
• After I verified the ability to receive time of day from the satellites, I worked on integrating that functionality with the use of the ESP32’s RTC peripheral, and building that into a custom library that will provide the caller with the most accurate time possible.

SPI Issues with the LCD Screen

<aside> ✅

Fix: In the User_Setup.h file in the library source code (terrible architecture by the way) make sure #define USE_HSPI_PORT is uncommented.

</aside>

• Recall that we are using an external library for driving our LCD screen via SPI. That library is TFT_eSPI.
• Simply changing the SPI pins between the breadboard version of the code and the version for the PCB did not work.
• The board would completely crash somewhere within in the tft.init() function call. (To be clear, this is a function provided by TFT_eSPI).
• So, I went back to the basics and ran the SPI testbench code from last week where it would simply send an incrementing byte across the line.
• Both SPI buses simply sending an incrementing/decrementing value separately does work. Code is below.

SPI Sanity Check

#include <Arduino.h>

// #include <TFT_eSPI.h>      // Include the graphics library
// TFT_eSPI tft = TFT_eSPI(); // Create object "tft"

#include <SPI.h>
#define SPI2 FSPI
#define SPI3 HSPI

#define LCD_CIPO 13
#define LCD_COPI 11
#define LCD_SCLK 12
#define LCD_CS 10 // Chip select control pin
#define LCD_DC 9  // Data Command control pin
#define LCD_RST 3 // Reset pin (could connect to RST pin)

#define SHARED_COPI 38
#define SHARED_CIPO 39
#define SHARED_SCLK 40

#define SD_CS 41
#define RFID_CS 42

SPIClass lcd_SPI(SPI2);

SPIClass shared_SPI(SPI3);

#define BUTTON_1 14

void setup(void)
{
  pinMode(BUTTON_1, INPUT_PULLDOWN);
  while (!digitalRead(BUTTON_1))
  {
  }

  Serial.begin(115200);
  Serial.println("begin");

  pinMode(LCD_CS, OUTPUT);
  pinMode(SD_CS, OUTPUT);
  pinMode(RFID_CS, OUTPUT);
  digitalWrite(LCD_CS, HIGH);
  digitalWrite(SD_CS, HIGH);
  digitalWrite(RFID_CS, HIGH);

  lcd_SPI.begin(LCD_SCLK, LCD_CIPO, LCD_COPI, LCD_CS);
  shared_SPI.begin(SHARED_SCLK, SHARED_CIPO, SHARED_COPI, -1);

  // tft.init();
  // Serial.println("tft init");

  // tft.setRotation(1);
  // tft.fillScreen(TFT_DARKGREY);
  // tft.setTextFont(2);
}

uint8_t l = 0x00;
uint8_t s = 0x00;
void loop()
{
  Serial.printf("lcd spi = %x shared spi = %x\\n", l, s);

  lcd_SPI.transfer(l++);
  shared_SPI.transfer(s--);

  delay(250);

  // tft.fillRectHGradient(0, 0, 160, 50, TFT_MAGENTA, TFT_BLUE);
  // tft.setCursor(10, 10);
  // tft.print("Horizontal gradient");

  // tft.fillRectVGradient(0, 60, 160, 50, TFT_ORANGE, TFT_RED);
  // tft.setCursor(10, 70);
  // tft.print("Vertical gradient");
}

• I went back and tried to make it not crash during tft.init() again.
• What ultimately fixed it was simply configuring the library to use the HSPI port. It’s a line in the User_Setup.h file that you uncomment. I’m attaching a full copy of the User_Setup.h file to this web page for reference.
  • Interestingly and frustratingly, the ESP32-S3 doesn’t necessarily have FSPI, HSPI, and VSPI ports anymore. Instead it has two SPI peripherals, SPI2 and SPI3. However, the old terminology appears to have stuck around for backwards compatibility reasons. ChatGPT explains it some more at the beginning of this conversation here (scroll up all the way to the top).
• Lastly, I added some SD card code from last week into this project, and I’ve verified that at the very least, I can display a static picture on the LCD screen and then

RFID Scanner

• I first encountered an issue where the RFID scanner would not communicate back to the ESP32.
• After looking at it with an oscilloscope, the SCLK and COPI lines looked normal. However, the COPI waveform looked incredibly weak.
• I eventually realized that I did not have CS connected to the RFID scanner itself.
  • Part of this oversight was due to the fact that on the module’s silkscreen, there is no “CS” pin labeled. It’s just that the pin labeled “SDA” also doubles as the CS pin while being used for SPI 💀
• After connecting a CS pin, the RFID scanner functioned just fine, and I was able to read the UID from an RFID tag.
• Next, I need to verify that the RFID, SD card reader, and LCD screen all work in conjunction with each other.

PCB Work

• Now that most of the elements on the PCB have been validated, and not to mention the deadline is drawing near, I went back to making edits to the schematic and redoing the layout.
• I decided to completely redo the layout because I added a few things to the schematic, I got rid of all jumper bridges (we’re not in prototype mode anymore), and I wanted to prioritize a compact and smooth form factor.

Photos

Current layout and 3d model (components not yet routed):

What happens when you forget to include a CS line on your SPI-connected device: