The hint for the builtin neopixleWrite() function has the wrong information. It shows
void neopixelWrite(uint8_t pin, uint8_t red_val, uint8_t green_val,
uint8_t blue_val)
In fact, at least on my Lolin ESP32 C3 Pico card the correct order of the colors are green, red and blue, not red, green and blue as described. The BlinkRGB.ino example also is incorrect in the color order.
Also there appears to be no online documentation for this "builtin" function.
Some pixels use a sequence of RGB, others use a sequence of GRB.
I do not know which library you use (and hence where this neopixelWrite() comes from) but e.g. the FastLed library allows you to specify that sequence; reasonably sure that Adafruit's NeoPixel library also supports it.
Complain to the authors of the library.
This is not a problem with the IDE, hence your topic has been moved to a more suitable location on the forum.
This is not a library that I've explicitly added via the Library Manager. It seems to be part of the board package for the ESP32 chips. The example code can be found in Examples under the ESP32 C3 board in the ESP32.GPIO.BlingRGB example. Since it is part of that package, I don't know who the authors are. Is it espressif? The only documentation that I could find is in the example and in the hint given as I type in the function.
I've now installed the ESP32 board package. I used the additional boards URL https://espressif.github.io/arduino-esp32/package_esp32_index.json. Is that the correct one?
Which board did you select? Asking because I can not straight away find the example.
void neopixelWrite(uint8_t pin, uint8_t red_val, uint8_t green_val, uint8_t blue_val)
...
...
int color[] = {green_val, red_val, blue_val}; // Color coding is in order GREEN, RED, BLUE
...
...
But if your board has a neopixel that expects the sequence RGB, that swap creates the problem.
I do not have your board but you can try the following. It's is a modified version of the BlinkRGB.ino example that I found by searching my PC.
/*
BlinkRGB
Demonstrates usage of onboard RGB LED on some ESP dev boards.
Calling digitalWrite(RGB_BUILTIN, HIGH) will use hidden RGB driver.
RGBLedWrite demonstrates controll of each channel:
void neopixelWrite(uint8_t pin, uint8_t red_val, uint8_t green_val, uint8_t blue_val)
WARNING: After using digitalWrite to drive RGB LED it will be impossible to drive the same pin
with normal HIGH/LOW level
*/
//#define RGB_BRIGHTNESS 64 // Change white brightness (max 255)
// the setup function runs once when you press reset or power the board
void setup() {
// No need to initialize the RGB LED
}
// the loop function runs over and over again forever
void loop() {
#ifdef RGB_BUILTIN
digitalWrite(RGB_BUILTIN, HIGH); // Turn the RGB LED white
delay(1000);
digitalWrite(RGB_BUILTIN, LOW); // Turn the RGB LED off
delay(1000);
neopixelWrite(RGB_BUILTIN, RGB_BRIGHTNESS, 0, 0); // Red
delay(1000);
neopixelWrite(RGB_BUILTIN, 0, RGB_BRIGHTNESS, 0); // Green
delay(1000);
neopixelWrite(RGB_BUILTIN, 0, 0, RGB_BRIGHTNESS); // Blue
delay(1000);
neopixelWrite(RGB_BUILTIN, 0, 0, 0); // Off / black
delay(1000);
#endif
}
void neopixelWrite(uint8_t pin, uint8_t red_val, uint8_t green_val, uint8_t blue_val){
rmt_data_t led_data[24];
static rmt_obj_t* rmt_send = NULL;
static bool initialized = false;
uint8_t _pin = pin;
#ifdef RGB_BUILTIN
if(pin == RGB_BUILTIN){
_pin = RGB_BUILTIN-SOC_GPIO_PIN_COUNT;
}
#endif
if(!initialized){
if((rmt_send = rmtInit(_pin, RMT_TX_MODE, RMT_MEM_64)) == NULL){
log_e("RGB LED driver initialization failed!");
rmt_send = NULL;
return;
}
rmtSetTick(rmt_send, 100);
initialized = true;
}
int color[] = {red_val, green_val, blue_val}; // Color coding is in order RED, GREEN, BLUE
int i = 0;
for(int col=0; col<3; col++ ){
for(int bit=0; bit<8; bit++){
if((color[col] & (1<<(7-bit)))){
// HIGH bit
led_data[i].level0 = 1; // T1H
led_data[i].duration0 = 8; // 0.8us
led_data[i].level1 = 0; // T1L
led_data[i].duration1 = 4; // 0.4us
}else{
// LOW bit
led_data[i].level0 = 1; // T0H
led_data[i].duration0 = 4; // 0.4us
led_data[i].level1 = 0; // T0L
led_data[i].duration1 = 8; // 0.8us
}
i++;
}
}
rmtWrite(rmt_send, led_data, 24);
}
I've copied the neopixel.Write() function (see above) and added it to the ino file; next I modified the line that caused the swap.
Note that this is a theoretical exercise for me as I don't have ESP32 based boards so can't test. If it works, great. If it does not work, rename the function to e.g. neopixelWriteNoSwap and call that function in loop() and test again
I do think so as neopxel.Write() is part of their board package.
The board type that I've selected is LOLIN C3 Mini. My actual board is a LOLIN C3 Pico, but there is no board type for the Pico. I'm using version 2.0.11 of the ESP32 package by Espressif. I found the example sketch in Examples.Esp32."Examples for Lolin C3 Mini".ESP32.GPIO.BlinkRGB. It is the same sketch that you found on your PC.
I can modify the sketch to do the swap. I was more interested in documenting the issue and understanding why it was happening. I suspect that it is due to the variety of ESP32 boards not all being the same, some RGB and some GRB.
Another issue that I noted elsewhere: A comment in the example says:
Calling digitalWrite(RGB_BUILTIN, HIGH) will use hidden RGB driver.
There is also code in the example for this, but this does not work. It would be nice if it did as it is the way most sketches turn the LED on. I suspect there is some incompatibility between the example sketch and the underlying espressif code. I found some obscure reference to this on the espressif site somewhere.
I also note that there is an alpha version of a new board package for ESP32 (3.0.x). Perhaps this fixes the issue, but I'm reluctant to try it because of other breaking changes in that package.
Unfortunately this feature only works when you are using one of the board definitions in which the RGB_BUILTIN macro was defined:
Unlike when calling the neopixelWrite function directly in your sketch, you can't make that feature work by defining the macro in the sketch code alone (because esp32-hal-gpio.c is a different "translation unit" than the sketch.
If you would like to add the RGB_BUILTIN macro definition to the lolin_c3_mini core variant used by your "LOLIN C3 Mini" board definition, I would be happy to provide instructions.
It does not. The RGB_BUILTIN macro is not defined for this board definition even in the newest 3.0.0 prerelease version of the platform:
As I mentioned in your other topic, this will probably only happen if some interested party makes the effort to contribute the change to the code. Ideally that would be the Lolin/Wemos company that manufactures these boards, but you might end up waiting a long time for that so I would recommend any user like yourself who wants this capability for their boards to do it.
OK, great. In order to provide you with detailed instructions, I need to learn the path of the variant file on your computer. I can extract that from the output from compiling a sketch on your computer when the verbose output preference is enabled. Please do this:
Select File > Preferences... (or Arduino IDE > Settings... for macOS users) from the Arduino IDE menus.
The "Preferences" dialog will open.
Check the box next to "Show verbose output during: ☐ compilation" in the "Preferences" dialog.
Click the "OK" button.
Select Sketch > Verify/Compile from the Arduino IDE menus.
Wait for the compilation to finish.
Right click on the black "Output" panel at the bottom of the Arduino IDE window.
From the context menu, click Copy All.
Open a forum reply here by clicking the "Reply" button.
Click the <CODE/> icon on the post composer toolbar.
This will add the forum's code block markup (```) to your reply to make sure the error messages are correctly formatted.
Press the Ctrl+V keyboard shortcut (Command+V for macOS users).
This will paste the compilation output into the code block.
Move the cursor outside of the code tags before you add any additional text to your reply.
Click the "Reply" button to post the output.
In case the output is longer than the forum software will allow to be added to a post, you can instead save it to a .txt file and then attach that file to a reply here:
Open a forum reply here by clicking the "Reply" button.
Click the "Upload" icon () on the post composer toolbar:
A dialog will open.
In the dialog, select the .txt file you saved.
Click the "Open" button.
Click the "Reply" button to publish the post.
Alternatively, instead of using the "Upload" icon on the post composer toolbar as described in steps (5) - (7) above, you can simply drag and drop the .txt file onto the post composer field to attach it.
If looking for it with your file manager or command line, note that the AppData folder is hidden by default. On Windows "File Explorer", you can make it visible by opening the "View" menu, then checking the box next to "☐ Hidden items".
Add the following line to the file:
#define RGB_BUILTIN LED_BUILTIN
Save the file.
Now upload the sketch to your board again. Hopefully this time the support for using pinMode and digitalWrite with the built-in RGB LED on the board will work.