WiFiNINA_Generic Library for WiFiNINA modules to support Teensy and more boards

khoih-prog

Well-known member
https://github.com/khoih-prog/WiFiNINA_Generic

How To Install Using Arduino Library Manager

New in v1.5.0

1. The original Arduino WiFiNINA library only supports very limited boards, such as: the Arduino Nano-33 IoT, MKR WiFi 1010, MKR VIDOR 4000 and UNO WiFi Rev.2.
This new library is based on and modified from Arduino WiFiNINA library to provide support for many more boards, such as SAM DUE, SAMD21, SAMD51, Teensy (4.0, 3.x, LC), AVR Mega, STM32, etc.

Features

With this library you can instantiate Servers, Clients and send/receive UDP packets through WiFiNINA. The board can connect either to open or encrypted networks (WEP, WPA). The IP address can be assigned statically or through a DHCP. The library can also manage DNS.

Sample Code

WiFiWebServer example

Code:
#include <SPI.h>
#include <WiFiNINA_Generic.h>

///////please enter your sensitive data in the Secret tab/arduino_secrets.h
char ssid[] = "****";        // your network SSID (name)
char pass[] = "********";    // your network password (use for WPA, or use as key for WEP), length must be 8+
int keyIndex = 0;                 // your network key Index number (needed only for WEP)

int status = WL_IDLE_STATUS;

WiFiServer server(80);

void setup() 
{
  //Initialize serial and wait for port to open:
  Serial.begin(115200);
  while (!Serial);

  // check for the WiFi module:
  if (WiFi.status() == WL_NO_MODULE)
  {
    Serial.println("Communication with WiFi module failed!");
    // don't continue
    while (true);
  }

  String fv = WiFi.firmwareVersion();
  if (fv < WIFI_FIRMWARE_LATEST_VERSION)
  {
    Serial.println("Please upgrade the firmware");
  }

  // attempt to connect to Wifi network:
  while (status != WL_CONNECTED)
  {
    Serial.print("Attempting to connect to SSID: ");
    Serial.println(ssid);
    // Connect to WPA/WPA2 network. Change this line if using open or WEP network:
    status = WiFi.begin(ssid, pass);

    // wait 10 seconds for connection:
    //delay(10000);
  }
  server.begin();
  // you're connected now, so print out the status:
  printWifiStatus();
}

void loop()
{
  // listen for incoming clients
  WiFiClient client = server.available();
  if (client) {
    Serial.println("new client");
    // an http request ends with a blank line
    boolean currentLineIsBlank = true;
    while (client.connected()) {
      if (client.available()) {
        char c = client.read();
        Serial.write(c);
        // if you've gotten to the end of the line (received a newline
        // character) and the line is blank, the http request has ended,
        // so you can send a reply
        if (c == '\n' && currentLineIsBlank) {
          // send a standard http response header
          client.println("HTTP/1.1 200 OK");
          client.println("Content-Type: text/html");
          client.println("Connection: close");  // the connection will be closed after completion of the response
          client.println("Refresh: 5");  // refresh the page automatically every 5 sec
          client.println();
          client.println("<!DOCTYPE HTML>");
          client.println("<html>");
          // output the value of each analog input pin
          for (int analogChannel = 0; analogChannel < 6; analogChannel++) {
            int sensorReading = analogRead(analogChannel);
            client.print("analog input ");
            client.print(analogChannel);
            client.print(" is ");
            client.print(sensorReading);
            client.println("<br />");
          }
          client.println("</html>");
          break;
        }
        if (c == '\n') {
          // you're starting a new line
          currentLineIsBlank = true;
        } else if (c != '\r') {
          // you've gotten a character on the current line
          currentLineIsBlank = false;
        }
      }
    }
    // give the web browser time to receive the data
    delay(1);

    // close the connection:
    client.stop();
    Serial.println("client disconnected");
  }
}


void printWifiStatus() {
  // print the SSID of the network you're attached to:
  Serial.print("SSID: ");
  Serial.println(WiFi.SSID());

  // print your board's IP address:
  IPAddress ip = WiFi.localIP();
  Serial.print("IP Address: ");
  Serial.println(ip);

  // print the received signal strength:
  long rssi = WiFi.RSSI();
  Serial.print("signal strength (RSSI):");
  Serial.print(rssi);
  Serial.println(" dBm");
}
 
Hi,
This looks appealing but I apologize for my ignorance and the simplicity of my questions.
1. How does the library interface to the internet? For example, via WiFi, what module, drivers etc are required?

2. More specifically, I would like to use some ESP8266 modules connected to a Teensy via a serial port and using AT commands.
I have seen criticism of AT commands, and I know there are many versions of them - so is this a real option?
For myself I've found power and ground plane to be critical with these - and they have been ok but limited with the AT commands. If this can work with AT commands etc that would suit me.

Thanks for the library in any case.
Kind regards - Richard
 
Hi,
If you're planning to use Teensy with ESP8266 AT-command, you have to use another library

Light-Weight-Credentials-WiFiManager-for-Teensy-SAM-DUE-SAMD-STM32- ESP8266-AT

1. Please have a look at the instructions and examples at GitHub page of ESP_AT_WM_Lite library

There are many AT firmwares, but I've tried and found out these following FW versions are the best and OK

- v1.54 (The best and latest) running OK @ 115K bauds
- v1.3.0.2, OK @ 115K bauds
- v0.9.2.2, OK @ 115K bauds

The way it's working can be simply illustrated as follows:

................Serial, AT-Command.............................................................................2.4GHz WiFi
Teensy <================> ESP8266 running AT-command Firmware <=============> WiFi Router <============> Internet <=========> Another Device


2. Certainly, the ESP AT-command shield is not as good as the real ESP8266 module because of the AT-command Serial interface limitation. For example 2K data limitation, speed and reliability of current AT command.

The better choice could be the WiFiNINA module, which is dual-cored ESP32-based and using SPI interface.

For WiFi communication @ 2.4GHz, the power and noise are critical for better reliability and speed.

Regards,

KH
 
Last edited:
Hi and thank you so much for the quick response.
That clears it up nicely. I'd never heard of 'NINA' previously so that clears it up.
FWIW - yes, I'm using AT commands from the latest version and implemented most of what I want but the 2K limit is seriously limiting and a job-killer. I transitioned to ESP32 and while that does work fairly well I much prefer Teensy for so many reasons.
I'll look around for a 'NINA' module.
Thanks again - cheers - Richard
 
Oh. Sorry. Meant to ask.
Is there a preferred, well stocked and available compatible module?
ta - Richard
 
Hi,
I'm so sorry I was not clear and created some misunderstandings in previous post.

1. The 2k AT-command buffer limitation will affect only if you create a very complicated HTML page (with graphics, etc.) and send the HTML page in just one AT command. Certainly there is some workarounds. But in general application, you might not have any issue. You have to test your application using ESP8266 before making big decision to use different type of module.
2. The ESP8266 is still the best, cost effective, and availability is good. For me, the reliability is still perfect, depending on the good hardware and code design (true for everything).
3. If you application requires complicated WebServer GUI, you can write Web GUI application to run independently on ESP8266 (directly, not AT firmware). Teensy will run another independent program, both communicate to each other via Serial interface, with some kind of simple protocol. You can do some research about Arduino MegaWiFi-R3 about the similar design, where you can use either AT-command or run independently.
4. The WiFiNINA family from U-Blox (W101, W102, W13x,.etc.) is an option if you need a complicated WebServer GUI, and don't want to have to develop more complicated 2 programs for 2 MCUs. The cost effectiveness, support and availability is not as good as that of ESP8266.

Hope it'll help,

Regards,
KH
 
Hi - thanks - no no no - your explanations are absolutely fine.
It is me - I didn't tell you my application.
I log data into I2C 32k byte eeproms then later upload to our server using "Post". So, bigger payloads mean something to me.
Thanks very much for your input and help.
Cheers - Richard
 
I have tried your library using a Teensy 4. I get the following diagnostic messages
\Arduino\libraries\WiFiNINA_Generic-master\src\utility\spi_drv.cpp::183]-W-Err cmd received


\Arduino\libraries\WiFiNINA_Generic-master\src\utility\spi_drv.cpp::275]-W-Reply error

\Arduino\libraries\WiFiNINA_Generic-master\src\utility\spi_drv.cpp::275]-I-A0,7F

Communication with WiFi module failed!
I can see the response on the MISO.
I have used the following pins
#elif defined(CORE_TEENSY)

#warning You have to modify pin usage according to actual connection for Teensy
#define PINS_COUNT (60u)
//NINA
#define NINA_GPIO0 (30u) //26
#define NINA_RESETN (26u)
#define NINA_ACK (23u)

#define SPIWIFI_SS 31 //PIN_SPI1_SS //24
#define SPIWIFI_ACK 23 //NINA_ACK //28
#define SPIWIFI_RESET 26 //NINA_RESETN //27
Any idea what can be happening?
 
As WiFiNINA W102 uses SPI, you have to connect and change the pin definitions in WiFiNINA_Pinout_Generic.h. Currently, the definitions are just a template and to be changed according to your applications and connections.

For Teensy 4.0, the pins used for SPI, by default, are as follows:
- MOSI => 11
- MISO => 12
- SCK => 13
- SS/CS => 10

Note: WiFiNINA W102 is a little bit difficult to use as it needs some more pins besides SPI bus
- GIPIO0 pulled low during startup for download firmware. GPIO0 pulled UP then DOWN for Normal Boot from Internal Flash. Assign a pin for this. For example Teensy 4.0 pin 6
- ACK pin. Assign a pin for this. For example Teensy 4.0 pin 5
- RESET pin. Assign a pin for this. For example Teensy 4.0 pin 2.

Please modify WiFiNINA_Pinout_Generic.h as follows and retest


Code:
....

#elif defined(CORE_TEENSY)


#if defined(__IMXRT1062__)
  // For Teensy 4.0
  #warning You have to modify pin usage according to actual connection for Teensy 4.0
  //#define PINS_COUNT           (60u)
  //NINA
  #define NINA_GPIO0  (6u)                             //6
  #define NINA_RESETN (2u)
  #define NINA_ACK    (5u)

  #define SPIWIFI_SS       10   //PIN_SPI1_SS           //10
  #define SPIWIFI_ACK      5   //NINA_ACK               //5
  #define SPIWIFI_RESET    2   //NINA_RESETN            //7

#elif ( defined(__MKL26Z64__) || defined(ARDUINO_ARCH_AVR) )

// For BOARD_TYPE      "TEENSY LC or 2.0"
  #warning You have to modify pin usage according to actual connection for Teensy LC or 2.0
  //#define PINS_COUNT           (60u)
  //NINA
  #define NINA_GPIO0  (6u)                             //6
  #define NINA_RESETN (2u)
  #define NINA_ACK    (5u)

  #define SPIWIFI_SS       10   //PIN_SPI1_SS           //10
  #define SPIWIFI_ACK      5   //NINA_ACK               //5
  #define SPIWIFI_RESET    2   //NINA_RESETN            //7

#else

  #warning You have to modify pin usage according to actual connection for Teensy 3.x
  //#define PINS_COUNT           (60u)
  //NINA
  #define NINA_GPIO0  (6u)                             //6
  #define NINA_RESETN (2u)
  #define NINA_ACK    (5u)

  #define SPIWIFI_SS       10   //PIN_SPI1_SS           //10
  #define SPIWIFI_ACK      5   //NINA_ACK               //5
  #define SPIWIFI_RESET    2   //NINA_RESETN            //7

#endif

....

For other Tensy boards. you can use this code snippet to know how SPI pins are predefined then use correspondingly

Code:
  Serial.println("Used/default SPI pinout:");
  Serial.print("MOSI:");
  Serial.println(MOSI);
  Serial.print("MISO:");
  Serial.println(MISO);
  Serial.print("SCK:");
  Serial.println(SCK);
  Serial.print("SS:");
  Serial.println(SS);
 
Thanks for a prompt response.
I have wired the additional pins, GPIO0, RESET and ACK, and defined them In WifiNINA_Pinout_generic.h.
I can program the part using serial passthrough, so that proves GPIO0 and RESET.
You say that you have to Pull GPIO0 high then low for normal boot, is that done by the example programs?. I currently have a 10K pullup on GPIO0 so it should be high on startup.
When I look at the State of GPIO0 it is low when the code is running.
 
When I print out the SPi pins, I get that SS is 10, but I defined SPIWIFI_SS as 31, am I setting the correct pin, or is there another location to define SS?
 
You say that you have to Pull GPIO0 high then low for normal boot, is that done by the example programs?. I currently have a 10K pullup on GPIO0 so it should be high on startup.

When I look at the State of GPIO0 it is low when the code is running.

The GPIO0 pull is done by the driver and you don't need to do anything. It's LOW and INPUT when running.

See in file src/utility/spi_drv.cpp

Code:
void SpiDrv::begin()
{
...
      SPIWIFI.begin();
      pinMode(SLAVESELECT, OUTPUT);
      pinMode(SLAVEREADY, INPUT);
      pinMode(SLAVERESET, OUTPUT);
      
      // The so-called W102 GPIO0 is **SYS_BOOT**/GPIO_27/RMII_CLK
      pinMode(NINA_GPIO0, OUTPUT);  // Pin is output
      
     // GPIO0 pulled UP then DOWN for Normal Boot from Internal Flash
      digitalWrite(NINA_GPIO0, HIGH);   // Pulse HIGH
      digitalWrite(SLAVESELECT, HIGH);  // then W102's CS HIGH
      digitalWrite(SLAVERESET, inverted_reset ? HIGH : LOW);  // reset W102 for 10ms
      delay(10);
      digitalWrite(SLAVERESET, inverted_reset ? LOW : HIGH); // reset W102 done
      delay(750);  // wait 750ms

      digitalWrite(NINA_GPIO0, LOW);   // pulse GPIO0 LOW
      pinMode(NINA_GPIO0, INPUT);   // make GPIO0 INPUT now.

When I print out the SPi pins, I get that SS is 10, but I defined SPIWIFI_SS as 31, am I setting the correct pin, or is there another location to define SS?



It's better to follow the printout as it's is correct to use.

I suggest you use the default Teensy 4.0 SPI pin to save time and avoid headache.

For Teensy 4.0, the pins used for SPI, by default, are as follows:

- MOSI => 11
- MISO => 12
- SCK => 13
- SS/CS => 10
 
I have a RA8875 display on the same bus (pin allocated, but board not fitted for these tests) It, is a display heavy application, I am also aware of the MISO issues, so I have buffered the MISO from both devices through a 74125 gate for both devices, is there no way to change the SS/CS allocation?
 
I Have checked on my storage scope (4 channel Rigol with SPI bus decoder), the CS seems to be working fine , when set to 31. And I get a response.
I have ordered in an Adafruit ESP32 airlift feather board, to see if it is a problem with the firmware image that I am using on the ESP32.
 
is there no way to change the SS/CS allocation?

Yes, you can redefine in WiFiNINA_Pinout_generic.h.

Add these lines into src/utility/spi_drv.cpp, then turn on _DEBUG_ to be sure you're doing correctly

Code:
#define _DEBUG_

...

bool SpiDrv::initialized = false;

void SpiDrv::begin()
{
#ifdef ARDUINO_SAMD_MKRVIDOR4000
      FPGA.begin();
#endif

#ifdef SPIWIFI_SS
      SLAVESELECT = SPIWIFI_SS;
#endif

#ifdef SPIWIFI_ACK
      SLAVEREADY = SPIWIFI_ACK;
#endif

#ifdef SPIWIFI_RESET
      SLAVERESET = (uint8_t)SPIWIFI_RESET;
#endif

#ifdef ARDUINO_SAMD_MKRVIDOR4000
      inverted_reset = false;
#else
      if (SLAVERESET > PINS_COUNT) {
        inverted_reset = true;
        SLAVERESET = ~SLAVERESET;
      }      
#endif

#ifdef _DEBUG_
#if (KH_WIFININA_DEBUG > 2)
      Serial.println("===============================");
      Serial.println("\nUsed/default SPI pinout: ");
      Serial.print("MOSI: ");
      Serial.println(MOSI);
      Serial.print("MISO: ");
      Serial.println(MISO);
      Serial.print("SCK: ");
      Serial.println(SCK);
      Serial.print("SS: ");
      Serial.println(SS);
      Serial.println("===============================");
      Serial.println("\nUsed/default NINA pinout: ");
      Serial.print("NINA_GPIO0: ");
      Serial.println(NINA_GPIO0);
      Serial.print("NINA_RESETN/SPIWIFI_RESET: ");
      Serial.println(NINA_RESETN);
      Serial.print("NINA_ACK: ");
      Serial.println(NINA_ACK);
      Serial.println("===============================");
      Serial.println("\nActual final pinout to used: ");
      Serial.print("SPIWIFI_SS: ");
      Serial.println(SPIWIFI_SS);
      Serial.print("SLAVESELECT/SPIWIFI_SS: ");
      Serial.println(SLAVESELECT);
      Serial.print("SLAVEREADY/SPIWIFI_ACK/NINA_ACK: ");
      Serial.println(SLAVEREADY);
      Serial.print("SLAVERESET/SPIWIFI_RESET/NINA_RESETN: ");
      Serial.println(SLAVERESET);
      Serial.println("===============================\n");
#endif
#endif

      SPIWIFI.begin();
      pinMode(SLAVESELECT, OUTPUT);
      pinMode(SLAVEREADY, INPUT);
      pinMode(SLAVERESET, OUTPUT);
      pinMode(NINA_GPIO0, OUTPUT);

      digitalWrite(NINA_GPIO0, HIGH);
      digitalWrite(SLAVESELECT, HIGH);
      digitalWrite(SLAVERESET, inverted_reset ? HIGH : LOW);
      delay(10);
      digitalWrite(SLAVERESET, inverted_reset ? LOW : HIGH);
      delay(750);

      digitalWrite(NINA_GPIO0, LOW);
      pinMode(NINA_GPIO0, INPUT);

#ifdef _DEBUG_
	  INIT_TRIGGER()
#endif

      initialized = true;
}

Redefine the pin to 20 in WiFiNINA_Pinout_generic.h.

Code:
#define SPIWIFI_SS       20   //PIN_SPI1_SS           //20


This is the Teensy 4.0 terminal output then


Code:
Used/default SPI pinout:
MOSI:11
MISO:12
SCK:13
SS:10
Used/default SPI pinout:
MOSI:11
MISO:12
SCK:13
SS:10
SPIWIFI_SS:20
SLAVESELECT:20
 
Last edited:
I have tried that and it responds with the correct pin, i.e 31, could this a firmware version issue on the ESP32, I am using the adafruit fork V1.6.0.
I am using ESP GPIO33, pin 9 on the module, or are we even checking ACK at this stage?
 
I'm confused now.

You are using some WiFiNINA-based board such as Adafruit AirLift FeatherWing with Teensy 4.0?

If so, the firmware on that board is a slight variant of the Arduino WiFiNINA core (latest is v1.3.0), and v1.6.0 is the latest. But I still don't have as well as haven't tested on that board to have experience to help you.
Did you test it on another Adafruit board, such as Adafruit Feather M4 Express to see if it's working OK and have some experience with the pin usage?
 
No, I have ordered a Airlift board, so that I could test it against a standard Teensy on a breadboard, ( to remove any hardware issues with my board) I cannot find a .bin for v1.3.0 so I have spent the last 3 hours trying to build the image, but I am stuck trying to get the path variable to work in windows. Is there a .bin file available, I have searched and cannot find it.
 
To update WiFiNINA firmware, the easier way is to use in Arduino IDE

Tools->W101/WiFiNINA Firmware Updater

Selection_361.png

or use the WiFiNINA Firmware GitHub but I think you have to compile the bin yourself.

Also have a look at to see how they do

1. Tools examples

2. FirmwareUpdater
 
Many thanks for your help and your perserverance.
At first the firmware updater won't buoild for the teensy.
I modified the firmware uploader sketch by changing line 335 of ESPbootRom.cpp to:-
ESP32BootROMClass ESP32BootROM(Serial7, 30, 26);
and this compiles, Serial 7 is the port connected to the ESP, and the one I use to program the ESP with ESP tools.,
I changed the GPIO0 and Reset pins accordingly, when I run download and run the sketch, then test connection, it reports that the sketch isn't running on the board.
Has the firmware updater been ported to the Teensy?
 
At first the firmware updater won't buoild for the teensy.

I still don't know why Teensy has anything to do here. Some questions:

1. Do you have a WiFiNINA-module and would like to run with Teensy 4.0?
2. If so, what kind of Module?
3. Can you use another way to program it directly, for example via USB directly, via another supporting board (e,g. using SAMD21, similar to Nano 33 IoT) or another programmer, instead via Teensy? Certainly if you're successful, it'll great and helpful but requires lots of works.
4. I can also ask some Ublox guys/reps to help show the easy way to reprogram the firmware for your WiFiNINA if the WiFiNINA-module is known. Now we're in the dark and still confused about what module you're using.
 
I am using the WROOM32 module as used by adafruit.
https://www.adafruit.com/product/3320
they make a breakout with onlythe module and a level shifter, and a buffer for MISO.
https://learn.adafruit.com/adafruit-airlift-breakout/overview.
I have reproduced the pull up resistors and the buffer.
I can program it successfully using the Serial passthrough code directly from the Teensy 4.
I can connect to the programming UART of the ESP32 using Serial7 on the teensy at 115200 baud, and it programs reliably every time. I set it to bootloader using the serial passthrough, disconnect the serial port from Arduino, and from esptools it programs.
With the default AT sketch, on the second UART of the ESP and default firmware (before programming) it responds to AT commands
I have loaded the adafruit V1.4 and V1.6 binary images, and what I think is a 1.3 image.
When I try to connect on my scope I see a command sent from the Teensy 4(on MOSI), a delay of approx. 100usec and a response from the ESP32 (on MISO), I see the busy line (GPIO0) toggling as commands are sent and responses from the ESP32. According to my storage scope, the commands are well formed.
When I set the code to debug, it always responds with a command error.
I have a click module expansion on my board, so I will connect the breakout board to these pins so that I can check if it is my hardware, but from what I have seen the hardware seems fine.
Am I correct in assuming that the code you have developed has only been tested against the ublox module? Am I correct in assuming the ublox module is a repacking of the ESP32?
I will update you when I test the adafruit breakout.
Many thanks for your help.
 
Wow! You have gone very far and finished a lot of things. Later, please post your experience somewhere for us to know how you do that.

For this WiFiNINA_Generic Library, we just test the WiFiNINA built-in or shields on

1. Nano 33 IoT (W102). OK
2. U-blox W102 (NINA W102) development module running original v1.3.0. OK. Lots of problems to be solved and already solved. See u-blox nina b issue #1

U-blox B302 <-> U-blox W102

Am I correct in assuming that the code you have developed has only been tested against the ublox module?

Both on Ublox development modules as well as built-in modules as in Nano 33 IoT

Am I correct in assuming the ublox module is a repacking of the ESP32?

Correct. I think it's ESP32-based

When I set the code to debug, it always responds with a command error.

Be sure the SS/CS pin used for WiFiNINA is not shared with another SPI slave. Turn on a lot of debugging, HW and SW.
 
Our contribution to the Covid 19 pandemic is that we have been working on a Rapidly Manufactured Ventilator system (RMVS). It is a full ventilator, not a bag pump, as it graphs and remotely logs, pressure, volume and flow, and we can detect start of patient breath and events such as coughs.
We originally used the MKr1010 and 5 inch RA8875 display, to test the state machine. We now have a working design based on commercially available pneumatics, a 9 inch display, along with a Teensy 4 module.
We are implementing Teensy threads to improve performance.
We use 4 LPS22 sensors and a commercially available low cost venturi to provide the data to support the calculations.
We are implementing a secure WiFi connection (using ATECC608) to a AWS portal we have created.
The Teensy 4 is fantastic for the calculations around airflow and pressure, but still bleeding edge in terms of support.
I have found a Teensy 3.1 project using the ESP32 Airlift, but it won't compile.
https://github.com/j3nsykes/OSC_propShield.
To test the ESP32, I have stripped the board down to just the PSU, teensy and the ESP32, and I can confirm that the Slave select is not shared.
It looks to me like a difference in the way the SPI operates between the Teensy3 & 4. It is most infuriating as it almost works, and the signals look clean.
I am tempted to start a new thread.
 
Can you move the SPI SS pin of Teensy to another pin and test. For example a Teensy unused pin such as 2, 3, 4 ??? then change the WiFiNINA_Pinout_Generic.h to retest
Your project is so important for many people I'm glad to give a free hand.
The way the SPI bus design is not so nice, every slave must use a separate CS/SS pin (certainly use can use I2C I/O expanders to control more slaves much easier, but still need external hardware and library mods).

I just fix the SPI issue on ESP32 for W5x00/ENC28J660 Ethernet shields that sporadically creates hanging issue, as the main SS (GPIO5) pin of ESP32 has been used for SPIFFS/Flash/EEPROM. Using GPIO13 on ESP32 fixed that sporadically hanging issue.
You'd better to try and test every free pin to be sure which one is still OK to use.

I don't know if if you have the same issue here with Teensy. But it's worth to move the SS pin away from default Teensy SS(pin 10) and test.

Another way to do is to design with ESP32 running as main processor, with WiFi and sensors and Teensy 4.0 as calculating/GUI co-processor. Then ESP32 communicates with and send necessary sensors' data to Teensy 4.0 via a serial bus for processing. Graphics intensive displaying/calculating functions can be handled by Teensy.
 
Last edited:
Back
Top