My thoughts as well. With better building blocks, the amount of RAM would suffice for many things - too much is currently wasted on multiple stacks and duplicated buffers. The assembly code that an RTFM app compiles down to is extremely efficient, fast and safe.chromebin wrote: I bet RAM usage would be significantly reduced when using the Rust programming language, combined with a run-to-completion scheduler. Such schedulers lead to significantly better code (no races guaranteed), less overhead and a single stack model (which much reduces RAM usage). Rust also brings better language abstractions and better tooling, and easily integrates with legacy C code.
What would you like to see in The Next Chip?
-
BuddyCasino
- Posts: 263
- Joined: Sun Jun 19, 2016 12:00 am
Re: What would you like to see in The Next Chip? Rust!
Re: What would you like to see in The Next Chip?
I would cram in the kitchen scale though, not necessarily with 24bit ADC, 18-20bit would do, with the added feature of being able to work with the ULP.cram every known peripheral in and the kitchen sink in as well
Everything to do with sensors, low power and low price.
You mean with an 8MB cache IDE HDD, I've seen many high spec'ed CPU's attached to those by dishonest mfgs. Compared to ESP8266 RAM is a big improvement though.It's like a laptop with an i3 CPU but an IDE HDD.
-
Vader_Mester
- Posts: 300
- Joined: Tue Dec 05, 2017 8:28 pm
- Location: Hungary
- Contact:
Re: What would you like to see in The Next Chip?
And not just RAM, but CPU speed is lost as well.
All the background things that FreeRTOS is doing is taking away CPU power.
The only thing here is that I guess Espressif thought that they include more RAM and more CPU than the 8266, so they can do more capability on the software side compared to the 8266, although the actual running speed of the ESP32 is technically the same or if not slower than the 8266 (on 1 core), and the usable RAM is also about the same.
All the background things that FreeRTOS is doing is taking away CPU power.
The only thing here is that I guess Espressif thought that they include more RAM and more CPU than the 8266, so they can do more capability on the software side compared to the 8266, although the actual running speed of the ESP32 is technically the same or if not slower than the 8266 (on 1 core), and the usable RAM is also about the same.
Code: Select all
task_t coffeeTask()
{
while(atWork){
if(!xStreamBufferIsEmpty(mug)){
coffeeDrink(mug);
} else {
xTaskCreate(sBrew, "brew", 9000, &mug, 1, NULL);
xSemaphoreTake(sCoffeeRdy, portMAX_DELAY);
}
}
vTaskDelete(NULL);
}Re: What would you like to see in The Next Chip?
My wishlist would include architecture to support multi-tasking. I know there is semaphore instructions in there already. But how about some memory segmentation (phys-virt mapping). That might even help with IoT's biggest problem: code security.
It would also be nice to see some signal processing capability (in addition to the multiply / accumulate stuff) with a view towards voice recognition.
Even if these can't be integrated on-die, a fast, dedicated bus to custom chips might do the job.
Plus 5 Volt tolerant I-O would be handy.
It would also be nice to see some signal processing capability (in addition to the multiply / accumulate stuff) with a view towards voice recognition.
Even if these can't be integrated on-die, a fast, dedicated bus to custom chips might do the job.
Plus 5 Volt tolerant I-O would be handy.
-
Vader_Mester
- Posts: 300
- Joined: Tue Dec 05, 2017 8:28 pm
- Location: Hungary
- Contact:
Re: What would you like to see in The Next Chip?
There is multi tasking already!pete_l wrote:My wishlist would include architecture to support multi-tasking. I know there is semaphore instructions in there already. But how about some memory segmentation (phys-virt mapping). That might even help with IoT's biggest problem: code security.
It would also be nice to see some signal processing capability (in addition to the multiply / accumulate stuff) with a view towards voice recognition.
Even if these can't be integrated on-die, a fast, dedicated bus to custom chips might do the job.
Plus 5 Volt tolerant I-O would be handy.
Read this: https://esp-idf.readthedocs.io/en/lates ... s-smp.html
The ESP32 have to CPU cores, you can run a task to a specific core, so the 2 can run parallel.
Also the FreeRTOS implements a task scheduler, and so much other stuff. I don't see how you can improve multi tasking on a uC any more than this.
Code: Select all
task_t coffeeTask()
{
while(atWork){
if(!xStreamBufferIsEmpty(mug)){
coffeeDrink(mug);
} else {
xTaskCreate(sBrew, "brew", 9000, &mug, 1, NULL);
xSemaphoreTake(sCoffeeRdy, portMAX_DELAY);
}
}
vTaskDelete(NULL);
}-
ESP_Sprite
- Posts: 9711
- Joined: Thu Nov 26, 2015 4:08 am
Re: What would you like to see in The Next Chip?
I think he means multi-process, with each process having a separate address space, rather than multi-threading, where the address space is (neccesarily) shared. We may implement something like an MMU capable of that in a future chip, it hasn't been decided yet.
Wrt speech recognition: The next chip will probably have some dedicated instructions that will prove useful for that.
Wrt 5-volt IO: Obviously, anything can happen, but I'd not count on any of our chips being explicitely officially 5V-compatible any time soon. The issue is that for the processes we use, the chip fabs don't want to give out any guarantees on 5V-compatibility. For instance, for the ESP32 and ESP8266, we're pretty sure that if you limit the current you can connect them to 5V and they won't die any time soon, but we don't want to give out any official OK for that as the fab can't give us guarantees and this issue is too small for us to invest the time and resources to do longevity tests on.
Wrt speech recognition: The next chip will probably have some dedicated instructions that will prove useful for that.
Wrt 5-volt IO: Obviously, anything can happen, but I'd not count on any of our chips being explicitely officially 5V-compatible any time soon. The issue is that for the processes we use, the chip fabs don't want to give out any guarantees on 5V-compatibility. For instance, for the ESP32 and ESP8266, we're pretty sure that if you limit the current you can connect them to 5V and they won't die any time soon, but we don't want to give out any official OK for that as the fab can't give us guarantees and this issue is too small for us to invest the time and resources to do longevity tests on.
Re: What would you like to see in The Next Chip?
Please be sure to fix SPI CS pre-transmission delay for full duplex mode (and other modes) in the next chip. It is such a shame that it works only in half duplex now. Generally speaking CS should be enabled before clock signal
Re: What would you like to see in The Next Chip?
May be more friendly name of GPIO?
I mean at current version of ESP32/ESP32-PICO-D4
"pad 10" == "IO34"
Or if we look the documentation https://www.espressif.com/sites/default ... eet_en.pdf
page 9
"IO 15" == "pad 21" == "RTC_GPIO 13" .... wtf???
why "pad 21" != "IO 15" != "RTC_GPIO13"?
Not bad if it is possible to realize hardware USB with a lot of EP
Not bad if it is possible to realize 2 ULPI interface
Wi-Fi 5GHz + WPA3
- esp32_01.png (81.04 KiB) Viewed 14601 times
"pad 10" == "IO34"
Or if we look the documentation https://www.espressif.com/sites/default ... eet_en.pdf
page 9
"IO 15" == "pad 21" == "RTC_GPIO 13" .... wtf???
why "pad 21" != "IO 15" != "RTC_GPIO13"?
Not bad if it is possible to realize hardware USB with a lot of EP
Not bad if it is possible to realize 2 ULPI interface
Wi-Fi 5GHz + WPA3
-
ESP_Sprite
- Posts: 9711
- Joined: Thu Nov 26, 2015 4:08 am
Re: What would you like to see in The Next Chip?
I get your gripe with the GPIOs. While we will not have direct GPIO <-> pad mappings (because it means we'd only be able to make one form factor chip - using the same silicon between e.g. the Pico and the 'bare' ESP32 chip would be impossible without messing up the pad numbering), we do get the weirdness of the RTC GPIO mapping and we will fix this in a future chip. Hardware USB will be possible (how much EPs did you have in mind, by the way, and did you have a specific purpose in mind?) but no ULPI support is planned for the immediate next chip. (Repetition of the disclaimer I stated a few times through this topic: these are estimations, and our roadmap may change in unexpected ways because of unexpected circumstances, no guarantees implied in any statements here.) Similarily, the immediate next chip will not have 5GHz, but we do have fairly advanced plans for a 5G chip. WPA3 is a software thing (mostly) and we may implement this even for the ESP32.
Who is online
Users browsing this forum: No registered users and 69 guests