Pin definitions T8/T9 & DAC1/DAC2 appear to be the wrong way round for Heltec & TTGO LoRa boards

[Paraphraser]

Hardware:

Board: TTGO LoRa32-OLED V1
Board: Heltec_WIFI_LoRa_32
Core Installation/update date: esp32-1.0.0

Description:

Both of these files:

   ./packages/esp32/hardware/esp32/1.0.0/variants/heltec_wifi_lora_32/pins_arduino.h
   ./packages/esp32/hardware/esp32/1.0.0/variants/ttgo-lora32-v1/pins_arduino.h

define the following pin mappings:

   static const uint8_t T8 = 32;
   static const uint8_t T9 = 33;
   static const uint8_t DAC1 = 26;
   static const uint8_t DAC2 = 25;

Those definitions are at odds with (a) the ESP32 Datasheet, (b) the ESP32 Technical Reference manual and (c) every other board in the variants folder that defines T8, T9, DAC1 and DAC2 as:

   static const uint8_t T8 = 33;
   static const uint8_t T9 = 32;
   static const uint8_t DAC1 = 25;
   static const uint8_t DAC2 = 26;

In other words, these two LoRa boards appear to have swapped the GPIO pins for T8/T9 and DAC1/DAC2. I wondered if the Touch and DAC pins could somehow be re-mapped but I have not found anything to support that theory so I suspect that the definitions for these two LoRa boards could be wrong.

[BBBits]

Seems you haven't had any reply ..
I have a project I work on with 2 different pc's .
one is using the latest sdk etc & the other is using one from oct 2017 .
had me scratching head when the sound stopped working when compiled with the latest ..
Would be nice if someone acknowledged & fixed the errors you found.

[lbernstone]

If you haven't noticed, there are 501 open issues in the tracker. This is a community driven project. If you want it fixed, fix it.

[chegewara]

Are you serious? This is issue tracker and this is issue reported. You dont want to fix it, ok, but telling people "go screw yourself" because someone does not feel confident enough to fix that code and create PR i not nice.

There is 501 open issues which means there is still 501 bugs that has not been addressed or people with privileges are too lazy to close issues that are fixed already.

[BBBits]

Correct , I had not noticed the 501 issues .
I also did not understand the process of getting things fixed .
If Phill doesn't get an opportunity to do the edit/PR thing , Then I'm happy to do so.

[Paraphraser]

Dear BBBits and others,

First, in the issue title I wrote that the pin definitions appeared to be the wrong way round because that was how it seemed to me. But, just because one person working alone (ie me) thinks something is a bug doesn't necessarily make it so. BBBits' comment provides additional practical evidence that this probably is a bug.

Second, I'm what you call a "casual user". If I find what I think is a bug, I will (a) do as much research as I can to make sure it hasn't been reported before, (b) try to nail down what I think is the likely cause, then (c) open an issue documenting my findings. I do this in the hope that people who actually do know what they are doing (which isn't me) will have the confidence to "do the edit/PR thing."

In short, I gratefully accept your kind offer of doing the edit/PR thing.

[BBBits]

Hi Phill,
I did the edit & pull request thing.
Missed out putting a ref to this Issue for the first one I did ( Heltek)
I could also have been a bit more descriptive in the headings , (instead of the default Update pins_arduino.h ) .
I'll be a bit more switched on next time .
BTW , I use vMicro inside AtmelStudio .
The right click on DAC1 "Goto Implementation" made it quick to find the source of the problem .

Barry

[mfarabee]

I am also seeing this issue on Pin 32 and 33 for a couple ESP32 boards I am using. I saw this on the Huzzah and a NodeMcu-32S.
What is weird is that I read the nun number (not using T8, T9, etc...). I specified pin 33, but I found pin 32 was the one it was reading.

I don't know if this helps.

[Paraphraser]

This particular issue is fixed in v1.0.2.