[esp32-wroom] No PlatformIO support?

[aneevuser]

I have a ESP32-WROOM 38-pin dev. board.

I have managed to write a 4 led blink program for this using the Arduino IDE, which seems to have full support for the board. I would prefer to use the VSCode-PlatformIO environment though.

However, I am unable to find any board spec. in PlatformIO that allows me to run the program successfully. I can find no board spec corresponding precisely to this board, but can get a program to build and download using the esp32dev spec. However, it doesn't work correctly.

I use GPIOs 32, 33, 25, 26 to drive the leds; in PlatformIO, with the esp32dev spec, the only led that actually blinks is that driven by pin 32. I'm guessing that the pinout known to esp32dev corresponds to some other board.

So the question: is there actual support for my board in PlatformIO at the moment, or am I doomed to using the Arduino IDE?

[DC1MC]

This doesn't work ?

https://docs.platformio.org/en/stable/boards/espressif8266/esp_wroom_02.html

[aneevuser]

This doesn't work ?

https://docs.platformio.org/en/stable/boards/espressif8266/esp_wroom_02.html

That's for an ESP8266-WROOM - I have an ESP32-WROOM.

[aneevuser]

Well, to add a little more info.

1) The precise board that I have is as sold here:

https://www.ebay.co.uk/itm/ESP32-Development-Board-ESP-32-38-pin-DevKitC-Layout-UK-Seller/322484359954

2) I think that I have now tried every vaguely possible ESP32 board spec. in PlatformIO, none of which allow the GPIO pins to be driven correctly, so it seems that this specific board has no current support in PlatformIO, unless I've managed not to test the correct spec. somehow.

So I guess that I'm heading back to Arduino-land for the time being, at least.

[Marco]

How about upesy_wroom

[aneevuser]

How about upesy_wroom

Sadly that doesn't work. The best that I found was nodemcu-32s, which correctly mapped 2 of 4 gpio pins. I'll take another look at the possibilities when I feel like wasting some more time.

Anyway, I can live with the Arduino stuff for now. It seems to support the board correctly, and I can use FreeRTOS (at least the task and queue stuff seems to work OK), and I've managed to get an I2C LCD board working, so it could be worse. I note that the compile/download stages are noticeably faster in PlatformIO, however.

I may look into how the board specs are written, to see how hard it is to write my own. Can't see much documentation for that at the moment though.

[Marco]

Espressif seems to pass a flag to the arduino core to set the PIO mapping. Which are here :

https://github.com/espressif/arduino-esp32/tree/master/variants

[dawnclaude]

I may be missing something, but why not use esp-idf extension on vscode? They made the installation much easier recently. I made the switch to it after I got annoyed by the slow code compilation on Arduino IDE.

[aneevuser]

I may be missing something, but why not use esp-idf extension on vscode? They made the installation much easier recently. I made the switch to it after I got annoyed by the slow code compilation on Arduino IDE.

You're probably not missing anything - I know next to nothing about either the ESP32 world or VSCode-PlatformIO, so I was unaware of the existence of this extension until you mentioned it.

I'm guessing this extension gives you raw access to the underlying ESP32 IDF, with no Arduino wrapper on top? Or am I confused? Don't you still need to select a specific board to build for, anyway, though? In which case, I'd still be facing the same problem?

[edit: just looked at some online reviews for this extension - they're bad - reee-ea-al bad...]

[florian-x]

I use PlatformIO with ESP32 modules, it works very well.

https://docs.platformio.org/en/latest/platforms/espressif32.html

I choose a default board, e.g., esp32dev. And one can use the Arduino framework, or ESP-IDF. Here's an extract of my platformio.ini file.

[env]
platform = espressif32
board = esp32dev
framework = arduino

[Lindley]

Just as an alternative you could used Atmel Studio 7 with the free Visual Micro plug in  which allows you to readily share files with the Ardunio IDE.

Also use HappyBuddha , a very good supplier, who advised that for those board we should use NodeMCU-32S which we have done without any problems.

[aneevuser]

Just as an alternative you could used Atmel Studio 7 with the free Visual Micro plug in  which allows you to readily share files with the Ardunio IDE.

I'll take a look at it. I'm not really too keen to use anything but the most widely used products though, due to the greater difficulty in finding on line support when problems occur.

Also use HappyBuddha , a very good supplier, who advised that for those board we should use NodeMCU-32S which we have done without any problems.

As I mentioned above, the nodemcu-32s board spec. in PlatformIO seems not to map the gpio pins correctly for this board, whereas I have no problem with the Arduino IDE.

[Lindley]

Just as an alternative you could used Atmel Studio 7 with the free Visual Micro plug in  which allows you to readily share files with the Ardunio IDE.

I'll take a look at it. I'm not really too keen to use anything but the most widely used products though, due to the greater difficulty in finding on line support when problems occur.

Also use HappyBuddha , a very good supplier, who advised that for those board we should use NodeMCU-32S which we have done without any problems.

As I mentioned above, the nodemcu-32s board spec. in PlatformIO seems not to map the gpio pins correctly for this board, whereas I have no problem with the Arduino IDE.

Well its Atmels own program and has been running for many years, check out the tutorials on ytube etc,  its software is mainly based on VS anyway.
Microchip who took over Atmel have now added Studio7 to their list of free programs.

PlatformIO is by comparison to Studio7 quite new and there is a lot of competiition out there, so perhaps less users /support ?

[tooki]

I have a ESP32-WROOM 38-pin dev. board.

I have managed to write a 4 led blink program for this using the Arduino IDE, which seems to have full support for the board. I would prefer to use the VSCode-PlatformIO environment though.

However, I am unable to find any board spec. in PlatformIO that allows me to run the program successfully. I can find no board spec corresponding precisely to this board, but can get a program to build and download using the esp32dev spec. However, it doesn't work correctly.

I use GPIOs 32, 33, 25, 26 to drive the leds; in PlatformIO, with the esp32dev spec, the only led that actually blinks is that driven by pin 32. I'm guessing that the pinout known to esp32dev corresponds to some other board.

So the question: is there actual support for my board in PlatformIO at the moment, or am I doomed to using the Arduino IDE?

OK, think about this: What's more likely? That the board support for the most common ESP32 board type is broken in what is likely the most popular programming environment for said board; or that you made a mistake somewhere?

I did some testing with a 38-pin WROOM dev board and can verify that blinking LEDs on those pins works just fine. However, you can make it fail by neglecting to set the pinMode to OUTPUT. Can you verify that you've done this?

Here is the exact code I tested:

Code: [Select]

#include <Arduino.h>

void setup() {
  // put your setup code here, to run once:
  //set pin modes
  pinMode(32, OUTPUT);
  pinMode(33, OUTPUT);
  pinMode(25, OUTPUT);
  pinMode(26, OUTPUT);
  //set all pins low to start
  digitalWrite(32, LOW);
  digitalWrite(33, LOW);
  digitalWrite(25, LOW);
  digitalWrite(26, LOW);
}

void loop() {
  // put your main code here, to run repeatedly:
  //chasing LEDs
  digitalWrite(32, HIGH);
  digitalWrite(33, LOW);
  digitalWrite(25, LOW);
  digitalWrite(26, LOW);
  delay(333);
  digitalWrite(32, LOW);
  digitalWrite(33, HIGH);
  digitalWrite(25, LOW);
  digitalWrite(26, LOW);
  delay(333);
  digitalWrite(32, LOW);
  digitalWrite(33, LOW);
  digitalWrite(25, HIGH);
  digitalWrite(26, LOW);
  delay(333);
  digitalWrite(32, LOW);
  digitalWrite(33, LOW);
  digitalWrite(25, LOW);
  digitalWrite(26, HIGH);
  delay(333);
}Commenting out the 4 pinMode() lines causes there to be no output.

Edit: P.S. I tested this in Arduino (1.8.16) and Arduino IDE (2.0.0-rc6) as well and the results are identical tp PlatformIO: setting the pin modes is mandatory.

[aneevuser]

OK, think about this: What's more likely? That the board support for the most common ESP32 board type is broken in what is likely the most popular programming environment for said board; or that you made a mistake somewhere?

Well, I spent ten years of my life as an embedded systems developer so I'm well accustomed to fucking up embedded systems, you can trust me on that. It was a very long time ago though, so I'm almost certainly worse now than in my youth.

Here is the code however; it works fine in the Arduino environment, and works to a varying extent depending upon which board spec, I choose in PlatformIO. I'm not particularly familiar with that environment though, so it's not impossible that I'm missing something obvious:

Code: [Select]

struct TaskParams
{
  int   led_gpio;
  float led_freq;
};

const int led_gpio_1 = 32;
const int led_gpio_2 = 33;
const int led_gpio_3 = 25;
const int led_gpio_4 = 26;

void BlinkTask(void *params);

void setup()
{
  TaskParams task1_params = {led_gpio_1, 0.22};
  TaskParams task2_params = {led_gpio_2, 0.42};
  TaskParams task3_params = {led_gpio_3, 0.82};
  TaskParams task4_params = {led_gpio_4, 1.62};

  xTaskCreate(BlinkTask, "Blink Task 1", 2048, &task1_params, 1, NULL);
  xTaskCreate(BlinkTask, "Blink Task 2", 2048, &task2_params, 1, NULL);
  xTaskCreate(BlinkTask, "Blink Task 3", 2048, &task3_params, 1, NULL);
  xTaskCreate(BlinkTask, "Blink Task 4", 2048, &task4_params, 1, NULL);
}

void BlinkTask(void *tparams)
{
  TaskParams *params = (TaskParams *) tparams;
 
  int   led_gpio = params->led_gpio;
  float led_freq = params->led_freq;
 
  pinMode(led_gpio, OUTPUT);

  int delay_ms = (int) 1000.0 / (2.0 * led_freq);
 
  while(1)
  {
    digitalWrite(led_gpio, HIGH);   
    vTaskDelay(pdMS_TO_TICKS(delay_ms));                   
    digitalWrite(led_gpio, LOW);   
    vTaskDelay(pdMS_TO_TICKS(delay_ms));
  }
}

void loop()
{                 
}


[tooki]

Then you have 10 years more professional experience in programming than I do!

Is that the entire code, or did you truncate it? I ask because there are two key changes needed in PlatformIO compared to using the Arduino IDEs:
1. You must include the Arduino.h header explicitly.
2. Unless you change the file ending to .ino (which isn't recommended because it undermines the IntelliSense code completion), you need to include function prototypes (which I do see you've done).

(Both of these things are harmless but unnecessary in Arduino IDEs.)

[aneevuser]

Then you have 10 years more professional experience in programming than I do!

10? Much more than that. Till I found something useful to do with my life...

Is that the entire code, or did you truncate it? I ask because there are two key changes needed in PlatformIO compared to using the Arduino IDEs:
1. You must include the Arduino.h header explicitly.
2. Unless you change the file ending to .ino (which isn't recommended because it undermines the IntelliSense code completion), you need to include function prototypes (which I do see you've done).

(Both of these things are harmless but unnecessary in Arduino IDEs.)

Oops, I lied. That code was from the horrible Arduino thing. The PlatformIO code is identical, but for an additional "#include <Arduino.h>"

I don't think that it's a coding problem - the fact that same code produces different results with different board specs suggests that the problem is in the board specs, rather than the code. I know too little about the environments to know where to start looking though, and to be honest, I don't really want to have to.

The Arduino IDE is clunky but will probably be OK for me for the time being. I'll return to this problem at some later time.

[tooki]

FYI, I just tried your code in PlatformIO and it worked right away. (Just had to include the Arduino header.) This pretty much conclusively confirms it's not a problem with the board definition in PlatformIO, which as I said, was spectacularly unlikely to be the case. (And a bit of a... bold accusation, to say the least.)

On the off chance that something in your build got borked and is now interfering, try cleaning the PlatformIO project (the trash can in the bottom toolbar, right next to the upload and serial monitor buttons), then uploading again.

Also, if you've closed and opened things (especially removing folders from the Explorer tab, the only way to "close" a project) make certain that you then reopened the project using the Open Project command in PlatformIO. Opening it just using the VS Code commands will not load everything that needs to.

[aneevuser]

FYI, I just tried your code in PlatformIO and it worked right away. (Just had to include the Arduino header.)

Which board spec did you use? That's pretty critical.

And did you actually check that the GPIO pins are toggling? You didn't just check that it compiles and downloads?

This pretty much conclusively confirms it's not a problem with the board definition in PlatformIO, which as I said, was spectacularly unlikely to be the case. (And a bit of a... bold accusation, to say the least.)

Software developers across the world are laughing maniacally at the suggestion that a software product is spectacularly unlikely to contain bugs.

On the off chance that something in your build got borked and is now interfering, try cleaning the PlatformIO project (the trash can in the bottom toolbar, right next to the upload and serial monitor buttons), then uploading again.

Also, if you've closed and opened things (especially removing folders from the Explorer tab, the only way to "close" a project) make certain that you then reopened the project using the Open Project command in PlatformIO. Opening it just using the VS Code commands will not load everything that needs to.

That's worth trying. In fact, I shall reinstall the whole thing from scratch at some point and try again.

[tooki]

FYI, I just tried your code in PlatformIO and it worked right away. (Just had to include the Arduino header.)

Which board spec did you use?

Same as in the earlier tests: "Espressif ESP32 dev module" (esp32dev) board definition with a 38-pin ESP32-WROOM board.

That's pretty critical.

No shit, Sherlock... You think that's not obvious to me after everything I've written and asked so far, including (before knowing you were a professional dev) asking you to verify that you were using the correct board definition that I know for a fact to be the correct one for that board type?!? (Programming them with PlatformIO is exactly what I've been doing quite a bit of the last several months.)

And did you actually check that the GPIO pins are toggling? You didn't just check that it compiles and downloads?

1. To me, "works" means the code must actually accomplish what it's supposed to do, which in this case is to blink LEDs. I said it "worked", not that it merely compiled and uploaded. I have 4 LEDs happily blinking in front of me at the 4 different blink rates you defined.
2. From my prior responses it should be obvious that I know that code that compiles need not necessarily work, given that I provided an explicit example of how to make the code compile but not work.

This pretty much conclusively confirms it's not a problem with the board definition in PlatformIO, which as I said, was spectacularly unlikely to be the case. (And a bit of a... bold accusation, to say the least.)

Software developers across the world are laughing maniacally at the suggestion that a software product is spectacularly unlikely to contain bugs.

No, but the board definitions are such a fundamental thing that for a board this popular, the chances that you found a new bug in the board definition asymptotically approach zero. See also the hyperlink I edited into my reply while you were writing your response.

On the off chance that something in your build got borked and is now interfering, try cleaning the PlatformIO project (the trash can in the bottom toolbar, right next to the upload and serial monitor buttons), then uploading again.

Also, if you've closed and opened things (especially removing folders from the Explorer tab, the only way to "close" a project) make certain that you then reopened the project using the Open Project command in PlatformIO. Opening it just using the VS Code commands will not load everything that needs to.

That's worth trying. In fact, I shall reinstall the whole thing from scratch at some point and try again.

Well, just try the opening from within PlatformIO and cleaning first, it's a ton less work!

[aneevuser]

No shit, Sherlock... You think that's not obvious to me after everything I've written and asked so far, ..

1. To me, "works" means the code must actually accomplish what it's supposed to do, which in this case is to blink LEDs. I said it "worked", not that it merely compiled and uploaded..

2. From my prior responses it should be obvious that I know that..

Impressive rant, designed to stamp the Authority of Tooki on the situation, and intimidate passers-by. I would have ranted slightly differently, but very good effort. (8/10 maybe?)

However, sadly, regardless of what your talents and abilities may be, I know nothing about you, or what "works" may or may not mean to you, or indeed what I may take as "obvious" from what you have written. I prefer always to check. That way, errors are more likely avoided.

But yeah, impressive and very evocative rant - reminds me of when my kids were teenagers - happy days!

No, but the board definitions are such a fundamental thing that for a board this popular, the chances that you found a new bug in the board definition asymptotically approach zero.

Yes, one would hope so, wouldn't one? However, when Mr Google shows me that people can find fundamental gpio code problems with specific ESP32 boards as recently as Nov. 2021, with bug fixes appearing as recently as April 2022, I stand somewhat less convinced than you that the ESP32 environment is a flawless example of software elegance.

https://github.com/espressif/arduino-esp32/issues/5947

Well, just try the opening from within PlatformIO and cleaning first, it's a ton less work!

Nah, I'll take off and nuke the entire product from orbit. It's the only way to be sure.

[tooki]

Impressive rant, designed to stamp the Authority of Tooki on the situation, and intimidate passers-by. I would have ranted slightly differently, but very good effort. (8/10 maybe?)

However, sadly, regardless of what your talents and abilities may be, I know nothing about you, or what "works" may or may not mean to you, or indeed what I may take as "obvious" from what you have written. I prefer always to check. That way, errors are more likely avoided.

But yeah, impressive and very evocative rant - reminds me of when my kids were teenagers - happy days!

You reap what you sow: My tone was a direct reaction to your attitude, arrogantly assuming there’s a bug, and then talking down to me (again, not considering the things I’d already expressly stated or asked)).

If you’d simply asked to verify the configuration without condescending (“That's pretty critical.”), it would have been different.

No, but the board definitions are such a fundamental thing that for a board this popular, the chances that you found a new bug in the board definition asymptotically approach zero.

Yes, one would hope so, wouldn't one? However, when Mr Google shows me that people can find fundamental gpio code problems with specific ESP32 boards as recently as Nov. 2021, with bug fixes appearing as recently as April 2022, I stand somewhat less convinced than you that the ESP32 environment is a flawless example of software elegance.

https://github.com/espressif/arduino-esp32/issues/5947

I didn’t say anything about the quality of ESP32 support in general. I said that the specific board type you have is almost certainly the most common ESP32 board in existence. It’s thus the most battle tested and consequently the least likely to have undiscovered bugs in the most basic functions of the board definition. The fact that you found reference to a bug in another, less mainstream board, one which uses a different ESP32 microcontroller, doesn’t contradict or disprove my statement in the slightest.

[aneevuser]

You reap what you sow: My tone was a direct reaction to your attitude, arrogantly assuming there’s a bug, and then talking down to me (again, not considering the things I’d already expressly stated or asked)).

Reap? Sow? Sounds a little biblical? What do you have planned for me next? Fire and brimstone? A pillar of salt? A plague of locusts o'er the land? Or even.... the Comfy Chair?!?

If you’d simply asked to verify the configuration without condescending (“That's pretty critical.”), it would have been different.

My dear Tooki, in your rather bizarre rage and ranting at my request for your board spec., you seem to have missed a rather important point: you hadn't actually told me which board spec. you used. Sadly, I can't read your mind, so I had to ask.

Anyway, I can report that having un- and re-installed the whole toolchain, both Vscode and PlatformIO, that I get precisely the same results: using board spec. esp32dev, precisely one led is driven (the one on GPIO 32 if my aging eyes don't lead me astray); when the code is built in Arduinoland, all is fine, with all 4 leds flashing as expected.

So there is clearly some difference somewhere in the two toolchains, but I don't have the time to go hunting down the problem. So here endeth my involvement with PlatformIO, at least temporarily.

I may take a look at the Atmel possibility, and if so will report back my findings.

[tooki]

My dear Tooki, in your rather bizarre rage and ranting at my request for your board spec., you seem to have missed a rather important point: you hadn't actually told me which board spec. you used. Sadly, I can't read your mind, so I had to ask.

Well, I stated clearly what board it is (namely, the same as you: an ESP32 (not ESP32-somethingelse) WROOM dev module, stands to reason I’d be testing it using the same board definition as you, since testing with anything else would be irrelevant.

Anyway, I can report that having un- and re-installed the whole toolchain, both Vscode and PlatformIO, that I get precisely the same results: using board spec. esp32dev, precisely one led is driven (the one on GPIO 32 if my aging eyes don't lead me astray); when the code is built in Arduinoland, all is fine, with all 4 leds flashing as expected.

But did you try cleaning the project, as I suggested? More than once I’ve had weird gremlins that cleaning (which then forces a complete rebuild) fixed. The cruft the cleaning cleans up is part of the project, not of the toolchain, so reinstalling the toolchain would have no effect on those.

[ve7xen]

I'm a bit confused by your assumption that this has anything at all to do with board definition. PlatformIO doesn't do any I/O mapping in board definition files. The entire board definition is a couple dozen lines of JSON, and most of that is about debug/programming. Pin mapping comes from the framework, which is again as far as I know (since I don't really use ESP32 or the Arduino framework) just cloned directly from upstream with no/minimal changes, so that's Espressif's responsibility.

If you think it's a board definition problem, just create your own in-project board definition anyway, it's trivial.