ESP32 Forum

I am switching over to the ESP32 from the Propeller and Arduino chips... could really use some help.
The SPIN and BASIC languages (which im good with) apparently are not compatible with the ESP32, so I started learning C++ using online tutorials and have completed the foundation classes so im at least able to write basic programs.
Unfortunately beyond making basic programs, the tutorials I have found so far dont help with things like manipulating pins on the ESP32.
For example I would like to write my own display routines for a WS2812 LED strip... this was pretty easy with the propeller chip, they had pre-made library files I could call in my own SPIN code to create amazing custom display routines.
Next step after that I'd like to create a bluetooth phone app for an interface.

Are there any good resources for learning how to control the ESP32 with C++?
Any help is appreciated! It's really tough starting over from scratch

You can use any C library/tutorial/documentation for the ESP32 you find from C++.

Probably the most important source of information is the official Espressif/IDF documentation, which is accompanied by a host of examples demonstrating almost everything you can do with the ESP32s (including WS2812 strips and Bluetooth).

Many libraries ("components" in IDF parlance) are available directly via the IDF Component Registry (also including WS2812).

To get first results quickly and postpone much of the learning you can look into the Arduino framework for ESP32 which is also C++.

The RTOS-based development paradigm and a relatively slow GPIO on the ESPs will require re-thinking of some of the approaches you may be used to especially from the Propeller. Broadly speaking: Whenever you need timing accuracy or response times significantly sub-millisecond you definitely want to use (one of) the ESPs' quite potent hardware peripherals and not emulate things in software.

That is definitely what I was looking for!
The WS2812 library is very straightforward

They recommend using RMT instead of SPI for WS2812 LED strips 'when dealing with a large number of led's'...
But dont say how many that is before it's considered 'a large number', I'm dealing with up to roughly 200, is that a large number?

Are there specific GPIO's for RMT like there are for SPI?

Does DMA work with RMT?

The propeller has 8-cores which allowed for running many concurrent processes... will that be a problem with the ESP32 if say I want to run many concurrent tasks i.e. BLE, accel/gyro readings, PWM(ws2812 leds), realtime user input/ouput, RTC, temp sensor...

They recommend using RMT instead of SPI for WS2812 LED strips 'when dealing with a large number of led's'...
But dont say how many that is before it's considered 'a large number', I'm dealing with up to roughly 200, is that a large number?

The thing with the RMT is that you'll need a RAM buffer of 32 bits for every bit you want to send to the LED strip. For 200 LEDs, that's 200x24x32 bits = 19.2kB. Not too crazy for an ESP32, but with SPI you'd probably only need 1/4th or 1/8th of that amount of RAM.

Are there specific GPIO's for RMT like there are for SPI?

Nope. You can route the RMT's signal(s) to any available GPIO pin.

Does DMA work with RMT?

Yes.
Generally, however, the newer ESP32 variants have ironed out some quirks, limitations, and "surprises" of the original ESP32, which is why I recommend to start straight with the ESP32-S2/-S3 or ESP32-Cx. Only the original ESP32 supports Bluetooth "Classic" though, which may or may not be relevant to you.
The IDF supports all variants of the ESP32 via the same APIs, so you can scale up or down the hardware later. For example, you can develop your application on an ESP32-S3, and later build and deploy it on the smaller ESP32-C3 for lower cost or power-consumption (if the C3 has sufficient resources for the application, of course).

The propeller has 8-cores which allowed for running many concurrent processes... will that be a problem with the ESP32 if say I want to run many concurrent tasks i.e. BLE, accel/gyro readings, PWM(ws2812 leds), realtime user input/ouput, RTC, temp sensor...

Shouldn't be a problem. FreeRTOS on the ESP32 does priority-based preemptive multi-tasking, so concurrent programming works just fine; with the added benefit that tasks (=FreeRTOS term for "threads") transparently migrate to whichever CPU core is available.
And, of course, there are a lot of interrupts to quickly and 'pseudo-concurrently' respond to hardware events. (But you don't normally interact directly with the interrupts because the peripheral drivers in the IDF deal with them for you.)

Btw: "Polling" ("while(!someFlag) { /* nothing */ }") is kind-of an anti-pattern in the FreeRTOS environment, and can and should be avoided most of the time.

From the 'LED Strip Driver' page:

You CANT connect other devices to the same SPI bus if it's been used by the led_strip, because the led_strip doesn't have the concept of "Chip Select".

Does each SPI pin have its own bus?
or are there a limited number of bus's that control multiple pins?
I dont know if this means whole clusters of pins will be unusable while using the led strip library

Is there somewhere showing the topology of each ESP32 version?
The S3 does sound better for my needs, I'm not sure if the C3 would be suitable or not

I dont know if this means whole clusters of pins will be unusable while using the led strip library

No. You can route each signal of a peripheral to a pin individually, or choose to not route it to a pin. For the LED strip, you'd only route the SPI's MOSI signal to a pin you like, leaving all other pins free for other uses.

Is there somewhere showing the topology of each ESP32 version?

Detailed information can be found in the respective Technical Reference Manual (TRM) and datasheet (ESP32-S3).

The S3 does sound better for my needs, I'm not sure if the C3 would be suitable or not

Go ahead and start with the S3. It also has way more IO pins than the C3.

Thanks for all the help!
I will do some experimenting on the wroom32 while waiting for S3 and C3 dev boards I'm going to order (merry xmas to me )
The small package size of the C3 is quite attractive... a minimal pcb width/height is important to me, length not so much.

For the LED strip, you'd only route the SPI's MOSI signal to a pin you like

My first time hearing of MOSI... how do I route an SPI MOSI signal?

how do I route an SPI MOSI signal?

Via the IO MUX and (optionally) the GPIO matrix like any other signal of an integrated peripheral (section 6 in the S3's TRM)
But you don't normally care much about the specific setup of the IO MUX and GPIO matrix. All IDF drivers and (most?) 3rd-party libraries just take one or more pin numbers as arguments upon initialization and make it so that the corresponding pins are configured correctly and connected to the peripherals' signals via the IO MUX/GPIO matrix as needed; like for example the UART driver.

I will do some experimenting on the wroom32 ...

If you haven't already, I suggest to also invest some time to familiarize yourself with FreeRTOS and specifically its inter-task communication/synchronization facilities (notifications, semaphores/mutexes, queues). These are important building blocks for making multiple tasks or tasks and ISRs work together.

Thanks for all the help!
Quite a lot to take in...
Having never used, I dont completely grasp FreeRTOS.
This is a new concept to me, usually I just write a program and flash it to the MCU.
Before I dive in I'd like to understand a little more.
So I should download and run ESP-IDF and also download FreeRTOS, then I write my programs to load through FreeRTOS?

Not quite.
FreeRTOS is included in the ESP-IDF and automatically compiled and linked into every IDF application you build, so nothing special to be done there.
An application (binary) on the ESP is statically linked and self-contained w.r.t. the "OS", drivers, and stuff like that.

The biggest challenge for starters often appears to be embracing the multi-tasking programming paradigm when one is used to writing a single main() loop which does 'everything' from other MCUs.

To me, the most important things to always keep in mind are:
1) When some piece of code (i.e. a task) has nothing to do because it needs to wait for something to happen, it should always release the CPU for other tasks to use. This is implicitly done by using one of the 'blocking' functions of FreeRTOS with a timeout argument, the trivial example of which is vTaskDelay(ticksToWait).
2) Multiple tasks, or ISRs and tasks, can only safely and efficiently interact via FreeRTOS's synchronization primitives. Just sharing a global variable between tasks is usually not going to cut it (see also 1 above).
It is also helpful to keep in mind that the ESP32(-S3) is dual-core, which implies that tasks may experience actual concurrency, and puts emphasis on the need to use proper synchronization via the OS.

And 3: Don't let FreeRTOS's function names upset you too much. Mistakes were made... and now they're backward-compatible.