Mistakes I found

[gitcnd]

The ESP32 D1 Mini pin labelled "TX" is GPIO03 (wrongly labelled on this PDF as GPIO01) Yes, I know that the ESP32 GPIO pin 03 is "RX" - my guess is that the D1 board labelled "RX" as "TX" for wiring reasons?

The pin labelled "RX" is GPIO01 (wrongly labelled on the PDF as GPIO03).

The following GPIO pins do not output any data: 6, 7, 8, 9, 10, 11, 35 Of the above, pins 9, 10, and 35 are labelled in dark-green with "can be used if not other function is used"... which is not entirely accurate. These pins should be labelled differently: "Cannot be used for output".

It might be worth noting that trying to use pin 6 will crash the chip (since it does).

The code I used to verify the above, is shown below. Use a test-meter on the pins to read the (backwards) binary GPIO pin numbers in morse code (dot=0, dash=1).

/* Sends "morse" binary ID out of every ESP32 GPIO pin. (backwards) dot=0, dash=1
 * e.g. dot dash dot dot = 2 (the builtin LED) */

#define NOSERIAL

#ifndef NOSERIAL
#include <SerialID.h>  // So we know what code and version is running inside our MCUs
SerialIDset("\n#\tv1.1-" __FILE__ "\t" __DATE__ "_" __TIME__);
#endif

#ifndef LED_BUILTIN
#define LED_BUILTIN 2 // ESP32 D1 mini pro
// #define LED_BUILTIN 33 // esp32_cam
#endif

struct MacBITS {
  union {
    uint8_t b[8];
    uint64_t mac;
  };
} macData; 

#define SPEED 250
#define GAP 2
#define DOT 1
#define DASH 3  
#define SPACE 6
#define NUMPINS 64 // ok=32   ( x6, )
uint8_t NUMBITS=0;
uint8_t pinbit[NUMPINS]; // What bit number are we upto in our binary flash loop
uint8_t pinskp[NUMPINS]; // Are we skipping this GPIO ? (0=no)
uint8_t pindly[NUMPINS]; // How long before we transition to the next bit (on/off timer)

void setup() {
  delay(500); // Give Arduino time to connect the serial...
#ifndef NOSERIAL
  SerialIDshow(115200); // starts Serial.
#endif
  macData.mac=ESP.getEfuseMac();
  // uint32_t chipId = 0; for(int i=0; i<17; i=i+8) { chipId |= ((ESP.getEfuseMac() >> (40 - i)) & 0xff) << i; }
  // Serial.print("Chip ID: "); Serial.println(chipId); // Chip ID: 597552
  uint16_t n=1;  while(n<=(NUMPINS-1)) { n=n*2; NUMBITS++; }

#ifndef NOSERIAL
  Serial.printf("ESP32 Chip model = %s Rev %d\n", ESP.getChipModel(), ESP.getChipRevision()); // ESP32 Chip model = ESP32-D0WDQ5 Rev 1
  Serial.printf("This chip has %d cores\n", ESP.getChipCores()); // This chip has 2 cores
  Serial.printf("MAC: %02X:%02X:%02X:%02X:%02X:%02X:%02X:%02X\n", macData.b[0],macData.b[1],macData.b[2],macData.b[3],macData.b[4],macData.b[5],macData.b[6],macData.b[7]); // MAC: 98:F4:AB:09:1E:30:00:00
  Serial.printf("Doing %d pins (%d bits): ", NUMPINS, NUMBITS); // : Doing 16 pins (4 bits)
#endif

  for(int i=0;i<NUMPINS;i++) { pinskp[i]=0; pindly[i]=0;}
  pinskp[6]=1; // Guru Meditation Error: Core  1 panic'ed
  //pinskp[7]=1; // Guru Meditation Error: Core  1 panic'ed
  //pinskp[8]=1; // Guru Meditation Error: Core  1 panic'ed
  //pinskp[9]=1; // Guru Meditation Error: Core  1 panic'ed

  for(int i=0;i<NUMPINS;i++) {
    pinbit[i]=0;
    if(!pinskp[i]) {
#ifndef NOSERIAL
      Serial.printf("%d ",i);
#endif      
      pinMode(i,OUTPUT); delay(50); digitalWrite(i,1); delay(50); digitalWrite(i,0); delay(50); // Crash it early, if it's going to crash...
    } else {
#ifndef NOSERIAL
      Serial.printf("x%d ",i);    
#endif
    }
    //if(!pinskp[i]) pinMode(LED_BUILTIN,OUTPUT);    
  }
} // setup

void loop() {
  for(int i=0;i<NUMPINS;i++) {
    if(!pindly[i]--) { // transition time
      if(pinbit[i]/2 > NUMBITS) { // end
        pindly[i]=SPACE; pinbit[i]=255; // will wrap below
        if(!pinskp[i]) digitalWrite(i,0);
        //digitalWrite(LED_BUILTIN,0);
#ifndef NOSERIAL
        if(pinskp[i]) { Serial.printf("x%d ",i); } else {Serial.printf("%d ",i);}
        if(i==NUMPINS-1) Serial.println("");
#endif
      } else if(pinbit[i]&1) { //gap
        pindly[i]=GAP;
        //if(i==NUMPINS-1) Serial.printf("%d gap=%d, ",i,pindly[i]);
        if(!pinskp[i]) digitalWrite(i,0);
        //digitalWrite(LED_BUILTIN,0);
      } else { // 1 or 0
        uint8_t j=1 << (pinbit[i] >> 1);
        if(i & j) pindly[i]=DASH; else pindly[i]=DOT;
        // if(i==NUMPINS-1) Serial.printf("%d bit=%d, ",i,pindly[i]);
        if(!pinskp[i]) digitalWrite(i,1);
        //digitalWrite(LED_BUILTIN,1);
      }
      pinbit[i]++;     // Advance to next bit (or LSB=gap)
    }
  } // i

    delay(SPEED);
} // loop

[r0oland]

I'll verify your findings at which point I am happy to change the image accordingly. Thanks for your detailed investigation.

[gitcnd]

I've done a pile more investigation, including working out which pins can be used for input (or not - as well as with pullups, or not), and making some other handy lists (including disconnected pins, pins needed for SD(1bit) and SD_MMC(4bit), pins that crash the board(6) or prevent sketch upload over serial(12), ) and more...

If you want to point me at "the image" and/or give me a clue about how to change it - I'm happy to do that work for you, as well as propose the addition of the extra stuff I've worked out.

Long story short: an ESP32_D1 diagram that doesn't include all the above is likely to cause a lot of headaches to newcomers - every bit (pardon the pun) that I've worked out above is always going to need to be something to keep in mind when wiring things up to these boards...

[gitcnd]

(my notes re above):

[r0oland]

Ok, you have clearly spent a lot more time with this MCU then I ever have!

If you are referring to this pinout, I took that simply from that website.

I did some digging and found this vector version of the pinout, but no Idea if that is just a copy or the "original": https://gitlab.com/gschorcht/RIOT.wiki-Images/-/blob/master/esp32/ESP32_pinouts.odg

I am not familiar with the odg format but seems to be a LibreOffice format. I am happy to replicate something nicer than my original sketch and close to the image above in Illustrator based on a mock-up from you. It seems quite a few people ended up using this repo so it's wort the update.

There is also this one, again with no original source I could find easily and only in jpg format...

[gschorcht]

I did some digging and found this vector version of the pinout, but no Idea if that is just a copy or the "original": https://gitlab.com/gschorcht/RIOT.wiki-Images/-/blob/master/esp32/ESP32_pinouts.odg

This is the pinout of the board as used by the RIOT-OS (https://doc.riot-os.org/group__boards__esp32__mh-et-live-minikit.html) which I created for the RIOT-OS documentation. Please note that it may differ from the pinout as provided by the Arduino core.

The ESP32 D1 Mini pin labelled "TX" is GPIO03 (wrongly labelled on this PDF as GPIO01) Yes, I know that the ESP32 GPIO pin 03 is "RX" - my guess is that the D1 board labelled "RX" as "TX" for wiring reasons?

The pin labelled "RX" is GPIO01 (wrongly labelled on the PDF as GPIO03).

Hm, really strange, I didn't realize that because I was always using the USB2UART bridge. The original pin assignment on the product page https://mhetlive.nodebb.com/topic/8/mh-et-live-minikit-for-esp32 also clearly states that the first pin of the left-hand header on the right-hand side is the TXD and thus the GPIO1 pin. This is also labeled accordingly on the PCB.

However, if I take a look into the schematic at https://i.imgur.com/EpE4dGj.jpg it seems in fact that the first pin of the left header at the right is the RXD0 pin :thinking: So not only the pinout is wrong but also the PCB.

This is even more worse because the Wemos D1 mini shields that should be pin compatible, expect as shown in the pinout, that is the TXD pin as the first pin and the RXD pin as the second pin.

The following GPIO pins do not output any data: 6, 7, 8, 9, 10, 11, 35

The reason for this is that GPIOs 6, 7, 8, 9, 10, 11 are the direct I/O pins of the SPI0 controller that are connected to the SPI flash. Since the SPI flash signals connected to GPIOs 9 and 10 are only active in the case of QOUT or QIO mode or are otherwise high-impedance, these GPIOs can very well be used as inputs and outputs in DOUT or DIO mode, which is controllable in RIOT-OS. This is probably not possible in Arduino core.

Of course, GPIO35 can only be as input because all GPIOs from 34 to 39 of the ESP32 are input-only pins. I thought there is no need to mark it in the pinout.

BTW, the labeling SPI<n>:xxx, UART<n>:xXD, PWM<n>:<m>, ADC<n> in the pinout is RIOT-OS specific and represents the GPIO usage as configured for the board in the RIOT-OS: https://github.com/RIOT-OS/RIOT/blob/master/boards/esp32-mh-et-live-minikit/include/periph_conf.h

[r0oland]

@gschorcht Dear Gunar, thanks for digging deeper into this. I am happy to accept any pull request or concrete suggestions for correction. But I presonally don't have time at the moment to look into this in more detail.

Is there any concrete thing I could fix?

[obar]

(my notes re above):

@gitcnd it's clear you walked into a minefield and took detailed notes so the rest of us could tread safely. I really appreciate that. I'm not entirely clear on your markup and maybe you could clear this up:

a     IOxx     b

• b = 0; input pull-up doesn't work
• b = 1; input pull-up does work
• a = 0, 1? Maybe pull-downs?

I've got a few other questions to clarify this great diagram but I'll try to figure things out on my own first so as to not swamp you. Thanks for your work on this!

@gschorcht I think your note about input only pins is worth including in the schematic symbol. It's easy to set this as an input pin instead of bidirectional, and I'd suggest the graphic style of 'input low' as it's an easy way to represent an input pin graphically. The 'output low' could similarly be used for IO that can only be configured as outputs. It would be great to indicate pins that have other special considerations, like those without functioning pull-ups. I could imagine a letter coding, so a pin might be labelled IO_XX(a,b) and on the table, someone could see that a means the pull-up doesn't work, b means in use with an SD card. Any thoughts on symbology @r0oland?

[gitcnd]

top-left corner of photo; "b" of "1" means that the pin turns to 0 when shorted through 10k resistor to ground when input_pullup is selected. "0" means the pin cannot be used with input_pullup.

"a" means the pin goes from 0 to 1 when shorted via 10k resistor to 3v3 (not using input_pullup of course)

[obar]

"a" means the pin goes from 0 to 1 when shorted via 10k resistor to 3v3 (not using input_pullup of course)

Thanks for that!

So do a=0 pins have a strong pull-down resistor (smaller than 10k) or do they basically not work as inputs?

I see some Xes on lines connecting GPIO labels, which mostly line up with the pins you noted don't work as outputs. GPIO1 (mislabelled as 3, as you pointed out before) also gets an X... also not output-capable or something else?

[gitcnd]

Sorry... I've forgotten those now. Might have been me marking "stuff that doesn't work" when I was running my program which tested outputs, before I realized that "doesn't work" is not such a simple concept? I'm away for a few weeks, but happy to do better tests or collaborate on some improved doc when I get back. I've got a bunch of these posters on my wall for a range of MCU's... I use them frequently!

[obar]

I think that makes sense, it "didn't work" and then there was more to it. Thanks so much for all of your help, I don't have the controller in hand yet but was able to lay out a PCB with the info you and @gschorcht provided. I can see a number of documentation changes that would be worth making here so it's easier to use this board, and I'd be glad to do some testing as well when mine come in.

I can think of a hardware change too; did anyone who made boards with this footprint find those drilled holes were too tight for header pins?