boards.txt board define issue for "WeMos D1 R1" board

[bperrybap]

The board specific define for "WeMos D1 R1" board define in boards.txt needs to be changed.
Currently it us using ESP8266_WEMOS_D1MINI

d1.name=WeMos D1 R1
d1.build.board=ESP8266_WEMOS_D1MINI
d1.build.variant=d1

The "WeMos D1 R1" board define should be changed to something different, perhaps something like ESP8266_WEMOS_D1 or ESP8266_WEMOS_D1R1 to indicate it is using a different variant than other Wemos "mini" boards.

d1.name=WeMos D1 R1
d1.build.board=ESP8266_WEMOS_D1R1
d1.build.variant=d1

The current board define of "ESP8266_WEMOS_D1MINI" is being used by other boards that are using the d1_mini variant.

d1_mini.name=WeMos D1 R2 & mini
d1_mini.build.board=ESP8266_WEMOS_D1MINI
d1_mini.build.variant=d1_mini

d1_mini.name=WeMos D1 R2 & mini
d1_mini.build.board=ESP8266_WEMOS_D1MINI
d1_mini.build.variant=d1_mini

d1_mini_pro.name=WeMos D1 mini Pro
d1_mini_pro.build.board=ESP8266_WEMOS_D1MINIPRO
d1_mini_pro.build.variant=d1_mini

Because of this "mini" board define being re-used by boards using different variants, there is no way for conditional compilation to tell the difference between a board using the d1_mini variant and the d1 variant.
It can make difference to some applications (I have a i2c diagnostic sketch that is one such sketch).

More details:

Each board in the boards.txt file can set a board specific define set in xx.build.board
While multiple boards can point to the same variant, using the same board define in multiple boards that points use variants creates issues.
For example,
"WeMos D1 R2 & mini" and "WeMos D1 mini Pro" both use the same variant "d1_mini" but each uses its own unique board define.
This does not create a problem.

What creates a problem is when two different boards, use the same board define but different variants.
For example:
"WeMos D1 R2 & mini" board uses board define: ESP8266_WEMOS_D1MINI
"WeMos D1 R1" board also uses board define: ESP8266_WEMOS_D1MINI
This is a problem since code that may want to know which variant is being used can't tell because the IDE does not pass in any variant information. The IDE only passes in a board name define and by using the same board define for different boards, there is no way to tell the boards apart.

[d-a-v]

This is true.
I will propose a PR to use ESP8266_WEMOS_D1R1 for the D1 R1 instead of _D1MINI.

[d-a-v]

#4304

[devyte]

A quick google says that d1 mini and D1 R2 have the same pinout, but d1 R1 has the same pins as Nodemcu v0.9 (I think). If that's true, maybe the R1 shouldn't be a different board?

[bperrybap]

@devyte D1 mini and D1 R2 share the same board type in boards.txt
For some reason all those boards decided to use Dn pin mapping symbols for their pin numbers and labels on the PCBs rather than the GPIO bit numbers.
Have a closer look at the variant files.
They don't have the same number of Dn symbols or map the Dn symbols to the same GPIO bit numbers.
d1 mini variant has symbols D0 to D8
d1 variant has symbols D0 to D15
nodemcu has symbols D0 to D10
Here is D1 R1 pin mapping symbols: (from the d1 variant file)

static const uint8_t D0   = 3;
static const uint8_t D1   = 1;
static const uint8_t D2   = 16;
static const uint8_t D3   = 5;
static const uint8_t D4   = 4;
static const uint8_t D5   = 14;
static const uint8_t D6   = 12;
static const uint8_t D7   = 13;
static const uint8_t D8   = 0;
static const uint8_t D9   = 2;
static const uint8_t D10  = 15;
static const uint8_t D11  = 13;
static const uint8_t D12  = 12;
static const uint8_t D13  = 14;
static const uint8_t D14  = 4;
static const uint8_t D15  = 5;

Here is the NodeMCU pin mapping from the nodemcu variant file:

static const uint8_t D0   = 16;
static const uint8_t D1   = 5;
static const uint8_t D2   = 4;
static const uint8_t D3   = 0;
static const uint8_t D4   = 2;
static const uint8_t D5   = 14;
static const uint8_t D6   = 12;
static const uint8_t D7   = 13;
static const uint8_t D8   = 15;
static const uint8_t D9   = 3;
static const uint8_t D10  = 1;

The use of Dn symbols vs GPIO bit numbers creates confusion.
Things like D4 is the same as 4 but D3 is the same as 0 or 5 depending on the board.
Most of the ESP8266 boards don't do this and don't create the symbols.
I have a test sketch that prints out the pin numbers for SDA and SCL but on the Wemos and NodeMCU boards, the values of SDA and SCL won't match what is printed on the PCB since the PCB shows Dn numbers.
To help resolved this I print GPIO numbers and Dn numbers for the pins (when available)
But to do that the code has to know how to do the mapping and in order to do that it has to know the variant at compile time. The symbols are not macros and the IDE doesn't pass in variant information (which is what I really want), so instead it uses the board define. But to use board defines you can't ever have two different boards that use different board variants using the same board define.

What can really help reduce confusion is what the LinkSprite LinkNode D1 board has done.
That board uses the Wemos D1 R1 board type.
It has great labelling printed on the PCB. It is UNO form factor so it has more room than some boards.
It prints the GPIOn numbers on one side and the Dn numbers on the other.

Honestly, things would be a lot simpler if the Dn pin names didn't exist and these particular boards just stuck to using the GPIO bit numbers, including printing them on the PCB.
It might mean that pin number labels might not appear to be sequential on the headers but using Dn doesn't really buy much.
The internal pin numbers always use GPIO bit numbers so the actual pin numbers are not sequential on the PCB anyway.
And in terms of portability since if some code wants to talk to digital pin N and digital pin N normally corresponds to a specific physical header location, having to use Dn instead of N requires code changes.
So having the Dn symbol didn't buy anything other than it is a symbol with a name that looks similar to the pin number.

[Hiddenvision]

Honestly, things would be a lot simpler if the Dn pin names didn't exist and these particular boards just stuck to using the GPIO bit numbers, including printing them on the PCB.

Don't think your gonna have much influence over the chineese clones.

[bperrybap]

Don't think your gonna have much influence over the chineese clones.

I agree, which is why I went to the trouble in my diagnostic tool to print both GPIO# and Dn or Pn (on the OAK board) when those alternate symbols are available based on knowing which board the code was compiled for.
This is what lead me to create the issue in the first place.
The proposed pull request solves the issue of not being able to tell the boards apart.

[d-a-v]

fixed by 85fb3d9