SparkFun Forums 

Where electronics enthusiasts find answers.

To Whom It May Concern:

First I think Sparkfun should answer their customers not force them to use a public forum! As a customer of numerous years and a fan of Sparkfun I am disappointed in this move.

We purchased the ESP32 Thing Plus and the DeadOnRTC board which brought about a few questions. We are trying to port code from a previous prototype leveraging the RedBoards and the DeadOnRTC to give you context.

On the RedBoard and the DeadOnRTC we connected the device as shown for a 4-wire SPI in the hookup guide:

RedBoard DeadOn RTC

Pin13 (PB5(SCK)) CLK
Pin12 (PB4(MISO)) MISO
Pin 11 (PB3(MOSI)) MOSI
Pin 10 (Pb2(ss/OC1B)) SS

To be clear we’d like to use the Arduino IDE & compiler for the ESP32 Thing Plus. Comparing the graphical diagrams for the ESP32 Thing Plus and the ESP32 Thing, pin 18 on the Thing Plus is labeled MOSI while on the Thing is labeled SCK, yet they both seem to map to the same pin on the ESP32. Is this a mistake?

I believe the correct hookup between the Deadon RTC and the ESP32 Thing is:

ESP32 Thing DeadOn RTC

Pin 5((GPIO5) V_SPI_CS0) SS

But the mapping on the ESP32 Thing Plus seems wrong based on the graphical data sheet

ESP32 Thing DeadOn RTC

Pin 5 ((GPIO5) V_SPI_CS0) CLK
?? (any GPIO pulled low) SS

Is there a mistake on the graphical data sheet for the thing plus? Is the ESP32 thing correct? Please advise on the best means of hookup of the ESP32 Thing Plus and the DeadOnRTC board.

I understand you and other customers have concerns about Tech Support moving to the forums, but we would like to keep these posts focused on assisting with questions and issues with SparkFun products and tutorials. If you have feedback regarding this transition or about the forums in general, we ask you please send a PM to TS-Feedback and we will be happy to address any concerns or issues you may have.

Now, for your question, both graphical datasheets are correct. The ESP32 (and other ESP ICs) have a pin multiplexing capability that allows you to assign things like UART, SPI and I2C to nearly any I/O pin you would like. The definitions are done via software in Arduino so just refer to the graphical datasheets for the correct connections. SS/CS can be assigned to any available I/O pin just make sure to adjust for that in your code. We cover this in more detail in the Hookup Guides for the ESP32 Thing and Thing Plus.

I hope this helps clear up any confusion regarding those graphical datasheets.
TS-Mark. Sorry this just adds to the confusion when you've point me to the ESP32 Thing Hookup Guide because of the following mapping for SPI bus and the libraries with the ESP32 (DS- data sheet ; GDS Graphical Data sheet):

SPI .........ESP32 DS......ESP32 Thing Plus GDS.........ESP32 THING GDS........esp32-hal-spi.c........SPI.cpp
MISO.......V_SPI_Q.............PIN19...............................PIN19.........................PIN19 (default).......PIN12(default)
MOSI.......V_SPI_O.............PIN18...............................PIN23.........................PIN23 (default).......PIN13(default)
SCK.........V_SPI_CLK.........PIN05...............................PIN18.........................PIN18 (default).......PIN14(default)
SS...........V_SPI_CSO.........PIN a5 (previous post)......PIN05.........................PIN05(default)........PIN15(default)

So each one are different and all are different to the graphical data sheets. When one evokes the command in Arduino'sIDE for
#include <SPI.h> which is the right hookup by default? I am using the Sparkfun Thing Plus ESP32VROOM trying to connect the SPI to the RFM69 Module on one project and the DeadonRTC on another. Neither instance the hookup as to the ESP32 Thing Plus Vroom is working, and the signals based on the the graphical data sheet make no sense.

Has anyone at Sparkfun connected the SPI bus in the manner shown on the graphical data sheet and has example code they're willing to share?

Well it appears there are two SPI buses on the ESP32WROOM evoked through the libraries the example code of SPI_MULTIPLE_BUSES.ino, which header reads:

/* The ESP32 has four SPi buses, however as of right now only two of
* them are available to use, HSPI and VSPI. Simply using the SPI API
* as illustrated in Arduino examples will use VSPI, leaving HSPI unused.
* However if we simply intialise two instance of the SPI class for both
* of these buses both can be used. However when just using these the Arduino
* way only will actually be outputting at a time.
* Logic analyser capture is in the same folder as this example as
* "multiple_bus_output.png"
* created 30/04/2018 by Alistair Symonds

Which states the default pins for vspi are SCLK = 18, MISO = 19, MOSI = 23, SS = 5 and Hspi are SCLK = 14, MISO = 12, MOSI = 13, SS = 15, which still confuses the matter when one uses the code below.... which SPI is being called? in #include <SPI.h>?

Oh and by the way from another post I found out that GPIO12 is off limits during loading code into the ESP32 Thing Plus because it causes a memory failure, so I am hoping you answer it's the v_spi configuration as default.

Edited by moderator to add code tags.
------------------------------------------CODE EXAMPLE from the RFM69 -----------------------------------------------------------------------------
Code: Select all
// Uses the RFM69 library by Felix Rusu,
// Original library:
// SparkFun repository:

// Include the RFM69 and SPI libraries:

#include <RFM69.h>
#include <SPI.h>

// Addresses for this node. CHANGE THESE FOR EACH NODE!

#define NETWORKID     0   // Must be the same for all nodes (0 to 255)
#define MYNODEID      1   // My node ID (0 to 255)
#define TONODEID      2   // Destination node ID (0 to 254, 255 = broadcast)

// RFM69 frequency, uncomment the frequency of your module:

#define FREQUENCY   RF69_433MHZ
//#define FREQUENCY     RF69_915MHZ

// AES encryption (or not):

#define ENCRYPT       true // Set to "true" to use encryption
#define ENCRYPTKEY    "TOPSECRETPASSWRD" // Use the same 16-byte key on all nodes

// Use ACKnowledge when sending messages (or not):

#define USEACK        true // Request ACKs or not

// Packet sent/received indicator LED (optional):

#define LED           13 // LED positive pin
#define GND           25 // LED ground pin

// Create a library object for our RFM69HCW module:

RFM69 radio;

void setup()
  // Open a serial port so we can send keystrokes to the module:
  Serial.print("Node ");
  Serial.println(" ready");  

  // Set up the indicator LED (optional):
  // Initialize the RFM69HCW:
  radio.setHighPower(); // Always use this for RFM69HCW

  // Turn on encryption if desired:
  if (ENCRYPT)

void loop()
  // Set up a "buffer" for characters that we'll send:
  static char sendbuffer[62];
  static int sendlength = 0;

  // In this section, we'll gather serial characters and
  // send them to the other node if we (1) get a carriage return,
  // or (2) the buffer is full (61 characters).
  // If there is any serial input, add it to the buffer:

  if (Serial.available() > 0)
    char input =;
    if (input != '\r') // not a carriage return
      sendbuffer[sendlength] = input;

    // If the input is a carriage return, or the buffer is full:
    if ((input == '\r') || (sendlength == 61)) // CR or buffer full
      // Send the packet!

      Serial.print("sending to node ");
      Serial.print(TONODEID, DEC);
      Serial.print(": [");
      for (byte i = 0; i < sendlength; i++)
      // There are two ways to send packets. If you want
      // acknowledgements, use sendWithRetry():
      if (USEACK)
        if (radio.sendWithRetry(TONODEID, sendbuffer, sendlength))
          Serial.println("ACK received!");
          Serial.println("no ACK received :(");

      // If you don't need acknowledgements, just use send():
      else // don't use ACK
        radio.send(TONODEID, sendbuffer, sendlength);
      sendlength = 0; // reset the packet


  // In this section, we'll check with the RFM69HCW to see
  // if it has received any packets:

  if (radio.receiveDone()) // Got one!
    // Print out the information:
    Serial.print("received from node ");
    Serial.print(radio.SENDERID, DEC);
    Serial.print(": [");

    // The actual message is contained in the DATA array,
    // and is DATALEN bytes in size:
    for (byte i = 0; i < radio.DATALEN; i++)

    // RSSI is the "Receive Signal Strength Indicator",
    // smaller numbers mean higher power.
    Serial.print("], RSSI ");

    // Send an ACK if requested.
    // (You don't need this code if you're not using ACKs.)
    if (radio.ACKRequested())
      Serial.println("ACK sent");

void Blink(byte PIN, int DELAY_MS)
// Blink an LED for a given number of ms
Hi again Terry,

The SPI pins labeled on the board and on our graphical datasheet are the default SPI pins for the ESP32 Thing Plus and the ESP32 Thing. I tested multiple examples like the Basic Readings Example for our BME280 Breakout with the ESP32 Thing Plus connecting to the labeled pins and had no issues. Just make sure to switch the CS/SS pin in your code to whatever pin you are running it to. In this case, I was using D14 with no problem.

It does look like our DS3234 RTC Library is incompatible with the ESP32. Most likely the compiler tool for Espressif ICs, esptool, does not work with how that library reads and writes registers, but I found an alternative library, RTC by Makuna, that you can either download from this GitHub Repository or you can install using the Arduino Library Manager tool (just search for DS3234). That worked just fine with a known good RTC module here connecting to the default pins on an ESP32 Thing Plus.

I have not had time to connect an RFM69 Module to an ESP32 Thing Plus yet, but Arduino does not throw any compile errors so that should work just fine. I hope this helps you progress with your project!

You'd stated : " I found an alternative library, RTC by Makuna, that you can either download from this GitHub Repository or you can install using the Arduino Library Manager tool (just search for DS3234). That worked just fine with a known good RTC module here connecting to the default pins on an ESP32 Thing Plus"

Could please supply the net list (pins map between the ESP32 Thing Plus to to DS3234 Module) you used in what you test as I am not clear by which default you're referring to? To be clear are you using the highlight green on the graphical data sheet (MISO = GPIO19, MOSI=18, SCK=GPIO5) or are using the light purple highlighted v_spi (MISO=GPIO19, MOSI=GPIO23, SCK=GPIO18, SS=GPIO5), which is your default?

Hi again Terry,

The ESP32 Thing Plus comes with a single SPI bus enabled by default on pins 19 (MISO), 18 (MOSI) and 5 (SCK). Those are the pins I used for my testing. I hope this helps clear up any confusion here.