ESP32 is finally real?
Re: ESP32 is finally real?
No I mean the ESP32 stuff. Just hoping we get some software & docs before hardware launch.
Re: ESP32 is finally real?
Am I reading this correct in that the next SDK version will not be compatible with the existing ESP31B modules then?Sprite_tm wrote: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.
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.
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?Sprite_tm wrote:(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.)
-
- Posts: 9708
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32 is finally real?
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.jmattsson wrote:Am I reading this correct in that the next SDK version will not be compatible with the existing ESP31B modules then?
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.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.
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
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/... .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?
Last edited by ESP_Sprite on Mon Jun 27, 2016 8:37 am, edited 1 time in total.
-
- Posts: 9708
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32 is finally real?
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.WiFive wrote:No I mean the ESP32 stuff. Just hoping we get some software & docs before hardware launch.
Re: ESP32 is finally real?
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.Sprite_tm wrote:The ESP32 SDK is SMP through and through and the ESP31s memory map doesn't lend itself nicely to that.
Wow, that was quick! Thanks!Sprite_tm wrote: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
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!Sprite_tm wrote: 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/... .
-
- Posts: 9708
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32 is finally real?
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.)jmattsson wrote: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.
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.
Re: ESP32 is finally real?
Best news I've heardSprite_tm wrote: one of our goals is to create register-level documentation for all peripherals
Re: ESP32 is finally real?
Very useful to know - thank you!Sprite_tm wrote: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
Any chance of -ffunction-sections being used on the SDK libs?
<3 <3 !Sprite_tm wrote:one of our goals is to create register-level documentation for all peripherals
Nifty! Though esptool.py has served remarkably well so far I must say.Sprite_tm wrote:the plan is for the ESP32 to have support in OpenOCD out-of-the-box.
-
- Posts: 9708
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32 is finally real?
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.jmattsson wrote:Sprite_tm wrote: Nifty! Though esptool.py has served remarkably well so far I must say.
Re: ESP32 is finally real?
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.Sprite_tm wrote: 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.
Who is online
Users browsing this forum: Majestic-12 [Bot] and 82 guests