ESP32 S3 pin number > 32 not supported?

[techtoys]

Hi

Sorry for the typo error on topic. It should be 35 not 32.

I am trying to drive WS2812 with ESP32S3. ON ESP32S3 there are pin number higher than 35 from GPIO35-48.
I find all high pin numbers are not supported by NeoPixelBus<NeoGrbFeature, NeoEsp32BitBangWs2812xMethod> strip0(PixelCount, PixelPin) whenever PixelPin>=35.

When I use a simple demo to set the high number pins to toggle all of them are working. So it is not a hardware issue.

Is there any requirement to enable pin number from 35?

John

[Makuna]

To control the tight timing, low level pin setting and clearing is used. These are 32bit registers where the bit represents the pin state. Since the original ESP32 only supported pins below 32 as output, the bitbang was never coded to support any other registers.

Are you sure you really want to use BitBang? With WiFi or Bluetooth active it is not a reliable method as it can get interrupted as those peripheral interrupts can't be suppressed.

The ESP32 S3 has hardware support (RMT) so you don't have to worry about this issue.

[techtoys]

Because I will need to drive 8x NeoPixel strips and it seems that RMT supports up to 4 channels, right?

[Makuna]

Correct, RMT on S3 is limited to 4 channels. Further S3/C3 at the moment don't support i2s parallel channels as the interface was changed and that work is tracked by an issue that is on my radar.
On ESP32 (original) or S2 you can use the i2s parallel mode to give you x8 or x16 hardware driven outputs.

Note, BitBang is not asynchronous like other hardware driven methods. Thus, it takes the CPU to drive the pin. This means with 8 channels; they will be updated one after the other and the send time of the data protocol to the LEDs is covered in a FAQ. There is little benefit to having 8 channels rather than just one longer one when using bitbang.

You can add an issue to track bitbang supporting IO pins above 32 for S3/C3

[techtoys]

Thank you very much, Makuna. I didn't know i2s can support x8 or x16 hw driven outputs. Day one I wanted to use BLE to configure the device but now I think if it is just for device configuration a Wifi server as an access point is also a possible route. In that case, it seems ESP32 S2 is a good choice for its higher pin count.

[Makuna]

There are specific examples on how to use I2s Parallel in the Arduino examples for NeoPixelBus.

[techtoys]

There are specific examples on how to use I2s Parallel in the Arduino examples for NeoPixelBus.

Yes, I saw the built-in example NeoPixel_ESP32_I2sParallel in the library folder. To fit ESP32S2, I needed to change declaration NeoPixelBus<NeoBgrFeature, NeoEsp32I2s1X8Ws2811Method> -> NeoPixelBus<NeoBgrFeature, NeoEsp32I2s0X8Ws2812xMethod> for ESP32S2. Without this change I am getting an error on compile.

Is it correct to apply NeoEsp32I2s0X8Ws2812xMethod for ESP32S2 and I will be able to drive x8 channel simultaneously with pin number say, 35-42?

With I2S hardware driven outputs, is the timing interrupted issue with concurrent Wifi connection solved?

[Makuna]

https://github.com/Makuna/NeoPixelBus/wiki/ESP32-NeoMethods#i2s
https://github.com/Makuna/NeoPixelBus/wiki/ESP32-NeoMethods#parallel-channels
I2S doesn't have pin restrictions other than input only pins can't be used. So check the board and specs for input only pins.
I2S hardware is DMA enabled and asynchronous. Once sending there is no CPU overhead and thus is not affected by WiFi or Bluetooths ISRs. All x8 or x16 are sent at the same time.

[robertlipe]

Another reason to avoid the high pin numbers on S3 is that those are often taken by the [DQO]IO pins used by the Flash (usally at least DIO, sometimes Q) and faster PSRAM (Double on cheaper boards, Octal on better boards). So they can be kind of a landmine. 35-37 and 45-45 are often off-limits. 39-42 are JTAG and can wiggle around to your surprise. Check your datasheets AND your schematics before blundering around in these pins. Good luck!

[techtoys]

Robertlipe

I understand. But I really need to reserve more pins for keypad and SPI, etc. So I have sacrificed the bluetooth feature and opt for ESP32S2 instead of S3. Have verified GPIO pins 42-37 with NeoPixel driver working in DMA (as Makuna suggested) and they all shine in a concurrent manner. Schematic extract is shown here.

Fortunately ESP32S3 and S2 modules are pin compatible. In the future when Bluetooth feature is mandatory, I will swap the module and wait when I2S driver for ESP32S3 is ready.

[robertlipe]

That can be legit. I was just encouraging you to check and be sure. I've just had to help toooo many people in other ESP32 projects that incur crashes during specific filesystem actions or specific memory transactions (and it's rarely the first for either or even the same time from run to run) and it's sometimes because they bought a board with the same amount of flash/ram, but because it's a newer revision, it uses more pins for faster SPI action and few things will make a computer as grumpy as having an address line "stuck" because it has an WS-2812 or some other device squatting on the line. Since you're using PIN37, we can infer you're using no SPIRAM of 8MB or larger and/or that it's not OSPI. 38 looks clear. 39-42 are used for the "old school" JTAG interface and probably fine for LEDs. You may see some pins with non-obvious power-on behaviour as some will be internally pulled high or low as they may power up to be outputs and thus driven or inputs with internal pull{up,downs}. Pins 38 and 39 have some definite long pulses on boot. atomic14 used those pins in a design of his and that flicker when the chip started confused the chip he was attaching enough that he had to lay his board out with changes and have them remade because they were terrorizing his attached chip. He got a pretty good video recently on the topic - it's the last link in the page: https://github.com/atomic14/esp32-s3-pinouts For plain ole LEDs or even WS2812's, a brief flicker is all you're likely to ever notice. Espressif is a bit annoying in advertising "48 GPIOS!!!" when about half of them have asterisks next to them limiting their use or with some weird behaviour. It's kind of like their "520K RAM" ... that's chopped up into IRAM, the secret paging RAM, RTC fast RAM, RTC slow RAM, PSRAM (coming in Dual, Quad, and Octal, each of which needs to be handled differently), RAM that you can't use for DMA, and memory that you can use only on Tuesdays if your last name has a prime number of letters. Pretty much all of the SOC APIs have weird little speed bumps at GPIO31->GPIO32 just because that's where they run out of bits to represent them easily. The CH32V307 with 80-somethnig GPIO's gets REALLY weird. :-) But back closer to the topic, with recent ESP-IDF, the https://docs.espressif.com/projects/esp-idf/en/v4.3/esp32/api-reference/peripherals/gpio.html#_CPPv410gpio_num_t gpio_num (and current is 5.2) gpio_num became a uint64_t internally, so things should Just Work. Now if code is relying on some Arduino abstraction over the "real" GPIO code, I can't much fake shock that the Arduino layer is broken given its birth on 8-bit CPUs. I don't REALLY know anything about the guts of NeoPixelBus, but this seems unlikely to be hard to fix. If you can confirm it's still a problem and Makuna can give me a slight push ("yes, the build page is current for a fresh checkout from trunk; I suspect THIS code....") I'm pretty sure I can stomp my way toward a fix IF you can provide a sample test program that doesn't work that should. I don't thnk I have any S3's WITHOUT PSRAM, so I may have to bluff my way through a "looks like this should work - it compiles, LOL" solution and iterate with you toward a fix. It probably won't be this week, but I can queue up a little time to helping the cause if you really can't fix it yourself. But I just dug through https://github.com/espressif/arduino-esp32/ and it looks like it's trying really hard to use SOC_GPIO_PIN_COUNT and the code in ESP-IDF looks like it's trying to set that for S3. It's upcasting from a uint8_t to a gpio_pin_t and not trying to bit twiddle itself, it's calling the ESP-IDF functions. If it had been broken in Arduino for the last 3.5+ years, there'd be cries in the bug system and I don't see anything relevant. Since the original report is so vague, it's not obvious what the search domain is. Attach a sample test program that fails on trunk, the actual failure mode, and i'll help take a look. Simpler the better. I'll take a ten liner that I can verify, even if only with a scope, over a 10,000 liner with 8 external dependencies that's a project to build of its own. It looks like my boards bring out 32, 34, and 35 so I think I have pins for GPIO 39, 41, 42 free for testing. I think.

…

On Mon, Jan 8, 2024 at 11:13 PM John Leung ***@***.***> wrote: Robertlipe I understand. But I really need to reserve more pins for keypad and SPI, etc. So I have sacrificed the bluetooth feature and opt for ESP32S2 instead of S3. Have verified GPIO pins 42-37 with NeoPixel driver working in DMA and they all shine in a concurrent manner. Schematic extract is shown here. 2024-01-09_13h07_56.png (view on web) <https://github.com/Makuna/NeoPixelBus/assets/6328296/8d0cd1ed-15a9-4507-90fa-f6b88284a45e> Fortunately ESP32S3 and S2 modules are pin compatible. In the future when Bluetooth feature is mandatory, I will swap the module and wait when I2S driver for ESP32S3 is ready. — Reply to this email directly, view it on GitHub <#741 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD3YCYKCXFELYKLYKSLTYNTGYBAVCNFSM6AAAAAA65QFFNSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DANRQGY2DG> . You are receiving this because you commented.Message ID: ***@***.***>

[techtoys]

Since you're using PIN37, we can infer you're using no SPIRAM of 8MB or larger and/or that it's not OSPI.

I am using a 8MB flash version without PSRAM.

You may see some pins with non-obvious power-on behaviour as some
will be internally pulled high

Yes, I saw that erratic behaviour. Using a mosfet switch to power up the strips only after all initialization lines executed. So far it seems good.

Below is a simple program that is working for now. Will see if it lasts...

//ESP32S2 module with 8MB Flash, no PSRAM
#include <NeoPixelBus.h>

NeoPixelBus<NeoGrbFeature, NeoEsp32I2s0X8Ws2812xMethod> strip1(24, 37);
NeoPixelBus<NeoGrbFeature, NeoEsp32I2s0X8Ws2812xMethod> strip2(24, 38);
NeoPixelBus<NeoGrbFeature, NeoEsp32I2s0X8Ws2812xMethod> strip3(24, 39);
NeoPixelBus<NeoGrbFeature, NeoEsp32I2s0X8Ws2812xMethod> strip4(24, 40);
NeoPixelBus<NeoGrbFeature, NeoEsp32I2s0X8Ws2812xMethod> strip5(24, 41);
NeoPixelBus<NeoGrbFeature, NeoEsp32I2s0X8Ws2812xMethod> strip6(24, 42);
NeoPixelBus<NeoGrbFeature, NeoEsp32I2s0X8Ws2812xMethod> strip7(24, 2);
NeoPixelBus<NeoGrbFeature, NeoEsp32I2s0X8Ws2812xMethod> strip8(24, 1);

//Must call show on ALL channels before it will send the data. It's a single action to send all 8 channels
void UpdateAll(void){
    strip1.Show();
    strip2.Show();
    strip3.Show();
    strip4.Show();
    strip5.Show();
    strip6.Show();
    strip7.Show();
    strip8.Show();
}

void setup() {
    strip1.Begin();
    strip2.Begin();
    strip3.Begin();
    strip4.Begin();
    strip5.Begin();
    strip6.Begin();
    strip7.Begin();
    strip8.Begin();
}

bool color_swap = false;
uint16_t dly_cnt;

void loop() {

 if(dly_cnt++ == 50){
    dly_cnt = 0;
    if(color_swap){
      color_swap = false;
      strip1.ClearTo(RgbColor(0, 0, 128));  //blue
      strip2.ClearTo(RgbColor(0, 128, 128));
      strip3.ClearTo(RgbColor(128, 0, 128));
      strip4.ClearTo(RgbColor(128, 64, 0));
      strip5.ClearTo(RgbColor(0, 0, 128));  //blue
      strip6.ClearTo(RgbColor(0, 128, 128));
      strip7.ClearTo(RgbColor(128, 0, 128));
      strip8.ClearTo(RgbColor(128, 64, 0));
    }else{
      color_swap = true;
      strip1.ClearTo(RgbColor(128, 0, 0));  //red
      strip2.ClearTo(RgbColor(128, 32, 0));
      strip3.ClearTo(RgbColor(64, 64, 0));
      strip4.ClearTo(RgbColor(32, 128, 32));
      strip5.ClearTo(RgbColor(128, 0, 0));  //red
      strip6.ClearTo(RgbColor(128, 32, 0));
      strip7.ClearTo(RgbColor(64, 64, 0));
      strip8.ClearTo(RgbColor(32, 128, 32));
    }
    UpdateAll();
  }

  delay(20);
}