Added ESP32 pin mapping for ESPDUINO-32 Wemos D1 R32

[Harvie]

This map is for relatively common ESP32 boards replicating the form factor of Arduino UNO.
This map allows use of such uno-compatible board with very popular
"Protoneer Arduino CNC shield" and is based on its pinout.
This makes perfect match for retrofiting older Arduino+GRBL based machines
with 32b microcontroler capable of running grblHAL and providing few extra IO pins (eg. for modbus #68 ).

These boards are sold under several names, for instance:

• ESPDUINO-32 (USB type B)
• Wemos D1 R32 (Micro USB)

[terjeio]

Coolant output is not going to work as pin 34 is input only.
A zero in front of single digit pin numbers such as GPIO_NUM_04 numbers fails to compile for me.

[terjeio]

... and coolant output defined as pin 34 stops at least spindle on pin working as well. Possibly all outputs?

I have added a check for input only pins used as outputs but that fails when I use the GPIO definition. A compiler bug?

Check fail to trap:

#define COOLANT_FLOOD_PIN   GPIO_NUM_34
#define COOLANT_MASK        (1ULL << COOLANT_FLOOD_PIN)

but traps:

#define COOLANT_FLOOD_PIN  34
#define COOLANT_MASK        (1ULL << COOLANT_FLOOD_PIN)

GPIO_NUM_34 is part of an enum and set expicitly to 34, when used in the shift expression it is read as 0 by the compiler making the COOLANT_MASK equal to 1.

[Harvie]

A zero in front of single digit pin numbers such as GPIO_NUM_04 numbers fails to compile for me.

Weird. The compilation went well for me. I will test all the individual pins with logic analyzer to see if the imputs are working as expected. I am aware of the input-only pins. that is common issue with esp32 designs.

[terjeio]

Weird. The compilation went well for me.

With idf.py?

Pin definitions in components\driver\include\driver\gpio.h looks like this in my installation:

typedef enum {
    GPIO_NUM_0 = 0,     /*!< GPIO0, input and output */
    GPIO_NUM_1 = 1,     /*!< GPIO1, input and output */
    GPIO_NUM_2 = 2,     /*!< GPIO2, input and output
                             @note There are more enumerations like that
                             up to GPIO39, excluding GPIO20, GPIO24 and GPIO28..31.
                             They are not shown here to reduce redundant information.
                             @note GPIO34..39 are input mode only. */
/** @cond */
    GPIO_NUM_3 = 3,     /*!< GPIO3, input and output */
    GPIO_NUM_4 = 4,     /*!< GPIO4, input and output */
    GPIO_NUM_5 = 5,     /*!< GPIO5, input and output */
...

Inputs were working for me, not sure if I tested the probe input though. A bit strange that the spindle enable output did not work when coolant output was routed to pin 34. When routed to pin 15 it worked. I did not test the other outputs.

Here is the test I have added (to driver.h):

#if IOEXPAND_ENABLE == 0 && ((DIRECTION_MASK|STEPPERS_DISABLE_MASK|SPINDLE_MASK|COOLANT_MASK) & 0xC00000000ULL)
#error "Pins 34 - 39 are input only!"
#endif

[Harvie]

Here is the test I have added (to driver.h):

Great. I was also planing to add this.

Inputs were working for me, not sure if I tested the probe input though.

It does weird thing. It seems to activate safety door (S) instead of probe (P).

[Harvie]

I have it commented out, maybe that's not good solution... Is there different way of disabling safety door pin mapping entirely? Also i have mist cooling commented.

//#define COOLANT_MIST_PIN    GPIO_NUM_36
//#define SAFETY_DOOR_PIN     GPIO_NUM_39
#define CYCLE_START_PIN     GPIO_NUM_36
#define PROBE_PIN       GPIO_NUM_39

[Harvie]

To be honest, it even kind of feels like ucommenting the #define BOARD_ESPDUINO32 in my_machine.h is not enough to use the map, because i've tried to put some giberrish to the map file and compiler did not complained. What is the preffered way to chose board?

[terjeio]

What is the preffered way to chose board?

That depends on which branch you are compiling for. For the master branch always my_machine.h, for the test branch CMakeLists.txt if compiling with a system that uses cmake (such as esp-idf), my_machine.h for others.

[terjeio]

I have just updated the test branch, this includes your PR and has an updated CMakeList.txt for selecting the board.

[Harvie]

Just found my espduino board is mislabeled on silkscreen (two pins were both marked as 36) and cycle start should actualy be 35:

Can you please fix it to look like this? CYCLE_START_PIN GPIO_NUM_35

[Harvie]

Also it feels that inputs are broken on grblHAL side.

I've used following arduino sketch to check that all input pin numbers are correctly marked on the board and it works like supposed in the arduino code (except for the mentioned cycle start pin which is actualy 35), but grblHAL inputs do not seem to work properly:

// the setup routine runs once when you press reset:
void setup() {
  // initialize serial communication at 9600 bits per second:
  Serial.begin(115200);
  // make the pushbutton's pin an input:
  
}

// the loop routine runs over and over again forever:
void loop() {
  // read the input pin:
  for(int i = 0; i < 50; i++) {
    if(i == 6) continue;
    pinMode(i, INPUT);
    if(digitalRead(i)) {
      Serial.print(i);
      Serial.print(" ");
    }
  }
  // print out the state of the button:
  Serial.println("");
  delay(1000);        // delay in between reads for stability
}

[terjeio]

Also it feels that inputs are broken on grblHAL side.

It is something weird going on when using the GPIO_NUM_xx enums for masks when xx > 31 (combined with pin numbers <= 31?).
Switch to bare numbers and it works:

#define RESET_PIN           2
#define FEED_HOLD_PIN       4
#define CYCLE_START_PIN     35
#define CONTROL_MASK        (1ULL << RESET_PIN|1ULL << FEED_HOLD_PIN|1ULL << CYCLE_START_PIN)

What makes it really weird is that the pin assignments for my CNC Boosterpack works, but perhaps due to all beeing > 31?:

#define RESET_PIN           GPIO_NUM_35
#define FEED_HOLD_PIN       GPIO_NUM_39
#define CYCLE_START_PIN     GPIO_NUM_36
#define SAFETY_DOOR_PIN     GPIO_NUM_34
#define CONTROL_MASK        (1UL << RESET_PIN|1UL << FEED_HOLD_PIN|1UL << CYCLE_START_PIN|1UL << SAFETY_DOOR_PIN)

Compiler error or expected behaviour? I do not know...
A fix will be removing the GPIO_NUM_ prefix?

[Harvie]

I tried to remove GPIO_NUM_ everywhere and the probe (pin 39) still does not work in grblHAL...

[Harvie]

I've checked with logic analyzer that STEP/DIR signals for XYZ axes are generated properly... But these are pins <30...

[terjeio]

I tried to remove GPIO_NUM_ everywhere and the probe (pin 39) still does not work in grblHAL...

Works for me. Another mislabeled pin? I had to add
#define PROBE_ENABLE 1
at the top of the driver map file to enable it though. I will add this as an option in CMakeLists.txt.

edit:
I did not have to add PROBE_ENABLE as this is the default - Eclipse was confusing me. I have added NOPROBE as an option to CMakeLists.txt instead.

[Harvie]

Works for me. Another mislabeled pin? I had to add

I've checked all pin numbers using arduino sketch and there was only one mislabeled. Is there anything that i need to configure to get list of active pins in status report (eg. XYP)? I don't know what was changed but i don't get that in recent builds and not sure why, maybe the pins are just not active...

[terjeio]

Is there anything that i need to configure to get list of active pins in status report (eg. XYP)?

No, I have tested with my sender and all shows up in the "LED" display as they should.

I don't know what was changed but i don't get that in recent builds and not sure why, maybe the pins are just not active...

A parsing problem due to additional elements? If you check with a terminal are they missing from the status report? If so did you forget to add pullup resistors for the input only pins?

I have now checked masks from enums with a different compiler - same issue. A switch to numbers only is required or the masks has to go in driver.c. Silly of Espressif of using enums for pin definitions and a mask for configuring them when this is not working properly in all combinations.

[Harvie]

Is there anything that i need to configure to get list of active pins in status report (eg. XYP)?

Actualy i had to set $10=255 to enable that... I originaly had that, but flashing the arduino sketch probably zeroed all the settings... Now the probe seems to work correctly even with #define PROBE_PIN GPIO_NUM_39...

[terjeio]

Oops - I have forgotten about that setting. BTW the CONTROL_MASK is not used in driver.c as input pins are set up individually.
I'll sleep on what to do with the ouput pins - perhaps best to keep the prefix?

[Harvie]

It seems that only problem now are the missing internal pullups. input-only pins (cycle start 35, probe 39) probably don't have that and will need external bias. and pin 2 (reset) seems to have pullup, but it is rendered unusable by onboard LED, which i will try to remove in order to recover the functionality.

[terjeio]

I'll sleep on what to do with the ouput pins - perhaps best to keep the prefix?

I decided to keep the prefix and added an array of pins to configure as outputs. Just commited to the test branch, note that I have only tested this lightly.