Memory consumption of BLE is really huge.
Would there be a way to rebuild portions of this to hardware ?
What would you like to see in The Next Chip?
-
Lucas.Hutchinson
- Posts: 79
- Joined: Tue Apr 26, 2016 5:10 am
Re: What would you like to see in The Next Chip?
While having a reduce memory footprint of ble would be awesome, it is not something that I would like to see.jumjum123 wrote:Memory consumption of BLE is really huge.
Would there be a way to rebuild portions of this to hardware ?
Including ble stack functionality directly in hardware would make it more limiting. If new functionality is released (such as ble 5.0 which was recently annpounced/released) then it would probably make it difficult to update the chip to support the newer standards (this would obviously depend on what changes, but it would also be hard to predict what might change).
Re: What would you like to see in The Next Chip?
You are right it would have to be pretty stable to put in ROM, but that doesn't mean you can't patch functions or link new versions. The ability to have some bt or wifi functionality in a wake stub would be great for battery applications. Obviously you aren't going to run a2dp in a wake stub but some limited operations like sending espnow or bt adv packets without powering on the flash would be a big advantage.
Re: What would you like to see in The Next Chip?
I know we're getting lots of features for a low price. But I can't understand why some fundamental things that we take for granted when using even cheaper micros from STM, NXP etc., are not possible
1. finer grained clock frequency control , with pll-mult and pll-div, should be able use bog standard crystals e.g. 16mhz 10ppm. Don't understand why 80MHz, 160MHz and 240MHz are the only "allowed" frequencies. If a minimum clock frequency is required to support a protocol stack, just state so in the documentation.
2. fast gpio clear, set and toggle
3. power consumption - if you're really trying to achieve 1.8V and are already at 2.2V why not go for 32nm or 28nm process, won't you achieve a lot more with this move - more dies per wafer, can hit 1.8V easily, less power consumption
4. wake from deep sleep from a timer, i.e. able to do what is now only possible with external chips like TPL5111 and/or DS3231
5. working peripherals e.g. i2c, without workarounds
6. double precision floating point arithmetic (edited)
7. something as fundamental as downloading to flash via jtag is only possible ONE YEAR AFTER mass production and general availability of the chips and a second chip rev ?! Here am just sticking my oar in on behalf of everyone who has no clue whether something that is a feature will actually ever work or with workarounds, or in the next chip. I don't know how much support and access you give to companies that work with you with NDAs, but having to figure out how i2s works and its limitations from the charity of other people who publish their projects on this forum (forget sample projects in the esp-idf distribution) is crazy. I don't work for a company anymore, my interest in ESP32 now is as a hobbyist looking for cheap value, and that it does deliver ! But if I did, as someone else pointed out, I would hesitate to recommend Espressif as a supplier for anything other than "toys and trinkets". So this particular longwinded request is : for the next chip, the "feature" I would like to see is solid hw, sw distribution with useful and comprehensive sample projects, and documentation !
1. finer grained clock frequency control , with pll-mult and pll-div, should be able use bog standard crystals e.g. 16mhz 10ppm. Don't understand why 80MHz, 160MHz and 240MHz are the only "allowed" frequencies. If a minimum clock frequency is required to support a protocol stack, just state so in the documentation.
2. fast gpio clear, set and toggle
3. power consumption - if you're really trying to achieve 1.8V and are already at 2.2V why not go for 32nm or 28nm process, won't you achieve a lot more with this move - more dies per wafer, can hit 1.8V easily, less power consumption
4. wake from deep sleep from a timer, i.e. able to do what is now only possible with external chips like TPL5111 and/or DS3231
5. working peripherals e.g. i2c, without workarounds
6. double precision floating point arithmetic (edited)
7. something as fundamental as downloading to flash via jtag is only possible ONE YEAR AFTER mass production and general availability of the chips and a second chip rev ?! Here am just sticking my oar in on behalf of everyone who has no clue whether something that is a feature will actually ever work or with workarounds, or in the next chip. I don't know how much support and access you give to companies that work with you with NDAs, but having to figure out how i2s works and its limitations from the charity of other people who publish their projects on this forum (forget sample projects in the esp-idf distribution) is crazy. I don't work for a company anymore, my interest in ESP32 now is as a hobbyist looking for cheap value, and that it does deliver ! But if I did, as someone else pointed out, I would hesitate to recommend Espressif as a supplier for anything other than "toys and trinkets". So this particular longwinded request is : for the next chip, the "feature" I would like to see is solid hw, sw distribution with useful and comprehensive sample projects, and documentation !
-
Lucas.Hutchinson
- Posts: 79
- Joined: Tue Apr 26, 2016 5:10 am
Re: What would you like to see in The Next Chip?
I'm not sure how do-able this would be with the wifi/ble crystal requirements.pataga wrote: 1. finer grained clock frequency control , with pll-mult and pll-div, should be able use bog standard crystals e.g. 16mhz 10ppm. Don't understand why 80MHz, 160MHz and 240MHz are the only "allowed" frequencies. If a minimum clock frequency is required to support a protocol stack, just state so in the documentation.
However having the same tight crystal requirements for the RF sections, but having a more separate/more de-coupled PLL system for the Processors would be ideal. Eg being able to set more arbitrary frequencies.
In addition to this, it would be good if the clock speed of peripherals could also be altered.
Eg have the core run at 240MHz, but run the uart at 10 or 20MHz, run the ADC at 10MHz etc so that more power can be saved. I am not sure if this is already part of the esp32, if it is then awesome!
-
mgleason_3
- Posts: 44
- Joined: Mon Nov 07, 2016 5:04 pm
Re: What would you like to see in The Next Chip?
More RAM and many of the other items would be great. But if I'm going to be honest, I came to the ESP32 because of it's low cost and support for certain features like Wifi and I2S. The only other thing that would be great (outside of a linux env 
) is if everything worked correctly and the documentation and examples where a lot more complete.
If the cost goes up, there's more competition, so there's a balance. If the Raspberry Pi W was available in volume...
One idea that might be nice is a low-cost "ready to integrate" module (RTI) (sort of a MVP... e.g. with voltage regulator for power and USB for burning, etc.), that's easy to buy, integrate and burn. The idea would be to let developers quickly/inexpensively take their products from development to initial production then later to volume production i.e:
) is if everything worked correctly and the documentation and examples where a lot more complete. If the cost goes up, there's more competition, so there's a balance. If the Raspberry Pi W was available in volume...
One idea that might be nice is a low-cost "ready to integrate" module (RTI) (sort of a MVP... e.g. with voltage regulator for power and USB for burning, etc.), that's easy to buy, integrate and burn. The idea would be to let developers quickly/inexpensively take their products from development to initial production then later to volume production i.e:
- Development on the developer module
- A "Rev1 production" product based on the RTI module
- and then later move production to a fully integrated Rev 2 or 3 based on the bare module when/if volume grows.
Re: What would you like to see in The Next Chip?
Just bumping this again, not sure if it got noticed first time.
jimbob wrote: 1. a means so that peripherals can communicate with each other without waking the main core. With the ULP available this probably makes sense to use that. Think of it as DMA for interrupts!
2. A configurable logic block on some (or all) of the I/O pins so I can create really simple logic functions in hardware which are fast (and again saves waking/instructions on a CPU)
3. (Apologies if I've missed it), but a way to use hardware to time hardware events. e.g. have a range of events to chose from that start and stop the timer. This could potentially be combined with the mechanism for 1&2.
-
ESP_Sprite
- Posts: 9709
- Joined: Thu Nov 26, 2015 4:08 am
Re: What would you like to see in The Next Chip?
I've removed some offtopic chatter here.
Leitukey: Your desire for more stability has been noted. Please do not keep spamming it here, there is no need for that; I'd rather not have to keep cleaning up the thread. If you have other technical improvements you can think of, unrelated to what you've already said, feel free to post it here.
We will try to keep high integration and low cost in mind in our future chips. With respect to documentation and examples: we're working on this. In general, the software and documentation team is always actively working on improving the SDK, and while we do not have enough manpower to make the SDK the holy grail of all that is good instantly, we do strive for something that is well-documented and can be used easily. If you feel we're failing terribly hard in some specific facet of this, or if you feel some specific example is particularily egregious, feel free to file an issue in the Github issue tracker.
Wrt multiple development modules: we already have a sort-of progression there: for development use, you can use a DevkitC; later when you make a device but don't want to be bothered by high-frequency PCB issues you can change to a Wroom32, and finally when your device is hot and you've ramped up production to many K-units, you can do the HF work and change to a 'raw' ESP32 chip to save a few extra pennies.
Wrt clock frequencies: I don't know the particulars of this, but it indeed is the WiFi and BT that have some very specific requirements wrt clocks. Wrt running the peripherals off lower clocks: from what I hear, this doesn't necessarily change power usage by *that* much, actually. For instance, we do nowadays switch off the clocks to peripherals we do not use entirely (we left all of them on in earlier esp-idf versions), and in a simple blink-type application, this nets us only 5mA or so of lower power usage. Now, I'm not saying that means running peripherals on lower clocks is something we'll never do, but I think it's more likely that we're going to allow people to switch any peripheral to 1 of 2 fixed frequencies (e.g. 80MHz or 1MHz) than give free reign to go wild in setting clock frequencies.
jimbob: I actually saw your post but forgot to mention I did. We actually are thinking about something like this indeed. Not sure if we'll make the ULP entirely superfluous, chances are it still more or less needs to run the show in deep sleep mode, but we have a few things in mind that make things easier. (About the ULP: I *can* tell you that programming the thing will get a lot easier because we're going to optionally have a different architecture ULP in the next version of the chip; an architecture that does have a full C compiler.)
Leitukey: Your desire for more stability has been noted. Please do not keep spamming it here, there is no need for that; I'd rather not have to keep cleaning up the thread. If you have other technical improvements you can think of, unrelated to what you've already said, feel free to post it here.
We will try to keep high integration and low cost in mind in our future chips. With respect to documentation and examples: we're working on this. In general, the software and documentation team is always actively working on improving the SDK, and while we do not have enough manpower to make the SDK the holy grail of all that is good instantly, we do strive for something that is well-documented and can be used easily. If you feel we're failing terribly hard in some specific facet of this, or if you feel some specific example is particularily egregious, feel free to file an issue in the Github issue tracker.
Wrt multiple development modules: we already have a sort-of progression there: for development use, you can use a DevkitC; later when you make a device but don't want to be bothered by high-frequency PCB issues you can change to a Wroom32, and finally when your device is hot and you've ramped up production to many K-units, you can do the HF work and change to a 'raw' ESP32 chip to save a few extra pennies.
Wrt clock frequencies: I don't know the particulars of this, but it indeed is the WiFi and BT that have some very specific requirements wrt clocks. Wrt running the peripherals off lower clocks: from what I hear, this doesn't necessarily change power usage by *that* much, actually. For instance, we do nowadays switch off the clocks to peripherals we do not use entirely (we left all of them on in earlier esp-idf versions), and in a simple blink-type application, this nets us only 5mA or so of lower power usage. Now, I'm not saying that means running peripherals on lower clocks is something we'll never do, but I think it's more likely that we're going to allow people to switch any peripheral to 1 of 2 fixed frequencies (e.g. 80MHz or 1MHz) than give free reign to go wild in setting clock frequencies.
jimbob: I actually saw your post but forgot to mention I did. We actually are thinking about something like this indeed. Not sure if we'll make the ULP entirely superfluous, chances are it still more or less needs to run the show in deep sleep mode, but we have a few things in mind that make things easier. (About the ULP: I *can* tell you that programming the thing will get a lot easier because we're going to optionally have a different architecture ULP in the next version of the chip; an architecture that does have a full C compiler.)
Re: What would you like to see in The Next Chip?
I think there are a couple of use-cases for finer grained clock frequency control.
1. use of the radio is only for OTA firmware upgrades and running diagnostics. E.g. weather sealed applications, or other situations like automobile interiors where you need a wire-free interface.
2. data logging applications where the radio is powered up once an hour or once a day or whatever. There could be light to heavy data capture and processing activity going on when the radio isn't on.
So here the controller is working as a generic embedded microcontroller almost all the time. That's why it would be great to be able to use it as I would an NXP or STM micro and run at the clocks I need (as others suggested controlling peripheral clocks too) to get the job done. With these micros power consumption is directly proportional to the cpu clock frequency, peripheral clock frequency and number of peripherals enabled. Why shouldn't the ESPxx work the same way ? And of course you should be able to fully power down the radio and power it up again without a reset.
Also repeating what someone else mentioned - stereo true 16bit DACs to go with the i2s ! Drool. Not "sort of working" DACs but accurate 16bit DACs.
1. use of the radio is only for OTA firmware upgrades and running diagnostics. E.g. weather sealed applications, or other situations like automobile interiors where you need a wire-free interface.
2. data logging applications where the radio is powered up once an hour or once a day or whatever. There could be light to heavy data capture and processing activity going on when the radio isn't on.
So here the controller is working as a generic embedded microcontroller almost all the time. That's why it would be great to be able to use it as I would an NXP or STM micro and run at the clocks I need (as others suggested controlling peripheral clocks too) to get the job done. With these micros power consumption is directly proportional to the cpu clock frequency, peripheral clock frequency and number of peripherals enabled. Why shouldn't the ESPxx work the same way ? And of course you should be able to fully power down the radio and power it up again without a reset.
Also repeating what someone else mentioned - stereo true 16bit DACs to go with the i2s ! Drool. Not "sort of working" DACs but accurate 16bit DACs.
-
BuddyCasino
- Posts: 263
- Joined: Sun Jun 19, 2016 12:00 am
Re: What would you like to see in The Next Chip?
Well in theory we've already got PDM mode, but in practice nobody managed to eliminate the noise. @Espressif: maybe you can say something?pataga wrote: Also repeating what someone else mentioned - stereo true 16bit DACs to go with the i2s ! Drool. Not "sort of working" DACs but accurate 16bit DACs.
Who is online
Users browsing this forum: No registered users and 140 guests