i tried these two but still same
i try before this one LED_BUILTIN
then i try this BUILTIN_LED also compile wrong
look in Arduino.h, wait no. Sorry, its "pins_arduino.h" in the variants folder. For the "standard" config, the line is
#define LED_BUILTIN 13
1 Like
Sorry, I'm lucky and never had to look. 
It's different for the several different processors I use.
Yes it is LED_BUILTIN but probably need to change the board from a ESP32 DA to ESP32S Devkit or one of the Devkit options
Dont forget pinMode(LED_BUILTIN, OUTPUT);
1 Like
What the man said. A while back I pointed out that you chose a bare module option.
1 Like
i will try this
noted
Please next time start your own thread if you have a problem, even if it is the same problem. Forum guidelines.
This thread was started by @f3lix0928 who may be reading additional replies.
To the original thread, you can create your own board definition and then it will run at least some software almost unmodified. The on board LED definition would be provided there.
There have been many issues with the symbol LED_BUILTIN over the years.
This includes in cores by Arduino.cc
Depending on the core the issues vary.
Some of the issues include:
- no LED_BUILTIN symbol
(Teensy, esp32, chipkit, pre-1.0.6 Arduino.cc AVR cores) - creating the symbol BUILTIN_LED instead of LED_BUILTIN
(esp8266) - creating the symbol as a const int instead of a macro
(arduino.cc switched to this in some of their early cores and after a big fight over it switched back to a macro)
I have contacted and attempted to work with the relevant core developers to resolve most of these issues over the years but a few still remain since in some cases the developers have outright refused to fix the issues.
I have a library that needs to use the LED_BUILTIN macro to determine at compile time if an on board LED is available.
I use this to ensure that the LED_BUILTIN macro exists.
// LED_BUILTIN define fixups for Teensy, ChipKit, ESP8266, ESP32 cores
#if !defined(LED_BUILTIN)
#if defined(CORE_TEENSY)
#define LED_BUILTIN CORE_LED0_PIN
#elif defined(ARDUINO_ARCH_ESP8266)
#define LED_BUILTIN BUILTIN_LED
// this is for cores that incorrectly used BUILTIN_LED instead of LED_BUILTIN
// esp32 core does this, they have LED_BUILTIN but it is a const not a define
// this works around that.
#elif defined(BUILTIN_LED)
#define LED_BUILTIN BUILTIN_LED
// special check for pre 1.0.6 IDEs that didn't define LED_BUILTIN
#elif (ARDUINO < 106 ) && ( defined(__AVR_ATmega328__) || defined(__AVR_ATmega328P__) || defined(__AVR_ATmega32U4__))
#define LED_BUILTIN 13 // IDE bundled AVR boards use pin 13 for builtin led
#elif defined(PIN_LED1) // chipkit
#define LED_BUILTIN PIN_LED1
#endif
#endif
--- bill
The other issue that comes up is that there is no way to know the active level on the pin needed to turn on the LED.
This means that as of today, it impossible to write portable code to turn on a built in LED even if you have the LED_BUILTIN symbol.
I have at various points in time tried to get some support for adding a core library function to turn on/off the built in led but so far have not ever gotten any traction.
The people opposed to this don't seem understand the issue.
Crazy that just trying to light up the built in LED could be such a mess.
--- bill
1 Like
I believe your board has a builtin RGB LED.
- To test it, just upload the sketch "BlinkRGB"
- File > Examples > ESP32 > GPIO > BlinkRGB
Newest Arduino IDE 2.0 with newest update for ESP32 boards, using LED_BUILTIN :
Node32s : Yes ✓
NodeMCU-32S : Yes ✓
ESP32 Dev Module : No 
LOLIN D32 : Yes ✓
DOIT ESP32 DEVKIT V1 : Yes ✓
OhMyGod
I had pushed the ESP developers to fix this stuff and and looks like in the latest platform, the ESP variants they have mostly fixed their built in led symbols.
Nearly all the variants that have declared a built in led have
a LED_BUILTIN const int symbol as well as a LED_BUILTIN macro
and then created a backward compatibility BUILTIN_LED macro for older code that used their incorrect symbol BIULTIN_LED.
So at this point in time you can use LED_BUILTIN and treat it as a macro for a conditional to determine if the board being built for has a declared built in led pin.
However, there are a few variants that haven't done this correctly like the variant fm-devkit. It declares the symbol LED_BUILTIN but does not define the macro.
So any board that uses that variant will not have a LED_BUILTIN macro even though the variant declared a LED_BUILTIN symbol.
There is lots of sloppiness in the ESP32 platform variant files and pin mappings.
A few have the Dn symbols but many do not. This creates portability issues within the platform as sometimes you need to use the Dn symbols but most don't have them defined.
This creates a pin mapping issue, since when looking at the physical boards and the silkscreening, they my have Dn printed next to the pins, but yet you may or may not need to use a Dn symbol vs a simple integer to access that particular pin.
There are also many other pin symbol macros that are not properly defined so this isn't just limited to the LED_BUILTIN symbol.
The ESP8266 platform has much better consistency and conformity in this area.
--- bill
I have about 10 different ESP32 boards, and I can vouch for that. To make it worse, some boards are clones and change the silk screen.
1 Like
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.