ESP32 Forum

No I mean the ESP32 stuff. Just hoping we get some software & docs before hardware launch.

We're working on the ESP32 SDK now and due to the changes in memory map and CPU interaction, it's diverged so much from the ESP31 that I don't see a backport happening any time soon.

Am I reading this correct in that the next SDK version will not be compatible with the existing ESP31B modules then?

While I'm here, could I request that the RTOS timer task priority gets pushed up to 2 like it is in the ESP8266 RTOS? It would be useful to be able to slot a task in below that priority without having to look at round-robin support or the idle hooks.

(On the other side of the coin: I'm pretty sure most people are going to agree the new SDK is an improvement; we have some features in it at least I personally am really happy with; for example, dual-core multiprocessing is going to be almost embarrassingly easy if you already have an app that uses the FreeRTOS primitives correctly.)

Sounds great! Do you still plan on having a mode where the SDK is locked to one core and the app can mess around freely on the other core? And by messing around I mean hard-looping with closed interrupts to implement high-precision timing for interacting with very picky external components. Or could that be achieved by implementing a task which higher priority than anything else which should hopefully see it stick to a core uninterrupted?

Am I reading this correct in that the next SDK version will not be compatible with the existing ESP31B modules then?

Don't count on it. The ESP32 SDK is SMP through and through and the ESP31s memory map doesn't lend itself nicely to that.

While I'm here, could I request that the RTOS timer task priority gets pushed up to 2 like it is in the ESP8266 RTOS? It would be useful to be able to slot a task in below that priority without having to look at round-robin support or the idle hooks.

The timers are hardwired to specific interrupts, but if I recall correctly we have multiple timers connected to interrupts of differing priorities. I'll see if I can make the core FreeRTOS timer configurable.

Edit: Added. You have the choice of interrupt level 1, 3 or 5. Whether this stays in the final SDK is subject to if this messes up other code, but for now it's in

Sounds great! Do you still plan on having a mode where the SDK is locked to one core and the app can mess around freely on the other core? And by messing around I mean hard-looping with closed interrupts to implement high-precision timing for interacting with very picky external components. Or could that be achieved by implementing a task which higher priority than anything else which should hopefully see it stick to a core uninterrupted?

Yes, the idea is to schedule only one task on the 2nd core and then to disable the timer interrupt there; maybe we'll write some porcelain to make that process more obvious. That way, you have the hardware timing of running on bare metal while you can still use a shared memory pool (malloc) and all the FreeRTOS queues/muxes/... .

No I mean the ESP32 stuff. Just hoping we get some software & docs before hardware launch.

Sorry, don't count on that too much. Getting all the docs ready for when the chip is available already takes a fair amount of effort, pre-releasing stuff to the general public is an extra load on the team and adds confusion with regards to multiple, maybe not 100% correct, versions of the documentation floating around on the Internet. Same goes for the SDK; making things ready for a release halfway through takes up time which at the moment we're better off spending on finishing the entire thing.

The ESP32 SDK is SMP through and through and the ESP31s memory map doesn't lend itself nicely to that.

Fair enough. I won't spend too much time trying to understand the cache window setup on the ESP31B then! Are there other areas that are likely to substantially change that I'd be better off avoiding in the interim? I'm working on getting NodeMCU onto the 32 (well, 31B currently) and would prefer to not have to re-do things needlessly.

Edit: Added. You have the choice of interrupt level 1, 3 or 5. Whether this stays in the final SDK is subject to if this messes up other code, but for now it's in

Wow, that was quick! Thanks!

Yes, the idea is to schedule only one task on the 2nd core and then to disable the timer interrupt there; maybe we'll write some porcelain to make that process more obvious. That way, you have the hardware timing of running on bare metal while you can still use a shared memory pool (malloc) and all the FreeRTOS queues/muxes/... .

Sweet! I'm seriously stoked about the ESP32 at this point! It's clearly shaping up to be the best thing since, well, the ESP8266!

Fair enough. I won't spend too much time trying to understand the cache window setup on the ESP31B then! Are there other areas that are likely to substantially change that I'd be better off avoiding in the interim? I'm working on getting NodeMCU onto the 32 (well, 31B currently) and would prefer to not have to re-do things needlessly.

Let's see... the way multicore processing is handled has changed (AMP -> SMP), the entire memory map has changed, we now have Newlib mostly in ROM (plus some other goodies), the GPIO block is changed wrt how you configure the functions, I2S has gotten a gazillion more functions... those are the things that spring to mind directly. Also, don't try too hard to reverse engineer the registers used in the ESP31 if you can't figure it out from the SDK code: one of our goals is to create register-level documentation for all peripherals except certain specific ones. (Namely BT, WiFi and one of the ADC channels, if I recall correctly.)

Also just dropping this here because of I'm spilling some beans already anyway: the plan is for the ESP32 to have support in OpenOCD out-of-the-box. We're using it extensively for our FPGA models of the ESP32 already and the code is fairly robust; we'll probably polish it up a bit and release it (plus maybe try to get it upstreamed) when the ESP32 is out.

one of our goals is to create register-level documentation for all peripherals

Best news I've heard

Let's see... the way multicore processing is handled has changed (AMP -> SMP), the entire memory map has changed, we now have Newlib mostly in ROM (plus some other goodies), the GPIO block is changed wrt how you configure the functions, I2S has gotten a gazillion more functions... those are the things that spring to mind directly. Also, don't try too hard to reverse engineer the registers used in the ESP31 if you can't figure it out from the SDK code

Very useful to know - thank you!

Any chance of -ffunction-sections being used on the SDK libs?

one of our goals is to create register-level documentation for all peripherals

<3 <3 !

the plan is for the ESP32 to have support in OpenOCD out-of-the-box.

Nifty! Though esptool.py has served remarkably well so far I must say.

Nifty! Though esptool.py has served remarkably well so far I must say.

Heh, we've also did some improvements in the flash upload code. Baudrate autodetecting can be bypassed so you can tell the ESP32 exactly what rate you're going to send data at, making higher baudrates much more stable. We can also compress the flash data while it's being sent (the ESP32 automaticallydecompresses it into flash) giving some extra upload speed increases.

Sorry, don't count on that too much. Getting all the docs ready for when the chip is available already takes a fair amount of effort, pre-releasing stuff to the general public is an extra load on the team and adds confusion with regards to multiple, maybe not 100% correct, versions of the documentation floating around on the Internet. Same goes for the SDK; making things ready for a release halfway through takes up time which at the moment we're better off spending on finishing the entire thing.

Just want to mention it is hard to decide to delay a product in development to wait for esp32 when we have no news of new TLS library, DMA capability, or even full gpio peripheral map. So things that are finalized should be documented and released asap.