What would you like to see in The Next Chip?

Post Reply
BuddyCasino
Posts: 263
Joined: Sun Jun 19, 2016 12:00 am

Re: What would you like to see in The Next Chip? Rust!

Postby BuddyCasino » Tue Jun 26, 2018 1:55 pm

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.
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.
Top
Mike C.
Posts: 1
Joined: Thu Jun 28, 2018 4:54 pm

Re: What would you like to see in The Next Chip?

Postby Mike C. » Thu Jun 28, 2018 5:20 pm

cram every known peripheral in and the kitchen sink in as well
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.
Everything to do with sensors, low power and low price.
It's like a laptop with an i3 CPU but an IDE HDD.
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.
Top
User avatar
Vader_Mester
Posts: 300
Joined: Tue Dec 05, 2017 8:28 pm
Location: Hungary
Contact:
Contact Vader_Mester

Re: What would you like to see in The Next Chip?

Postby Vader_Mester » Fri Jun 29, 2018 9:03 am

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.

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);
}
Top
pete_l
Posts: 2
Joined: Fri Mar 16, 2018 11:18 am

Re: What would you like to see in The Next Chip?

Postby pete_l » Sun Jul 01, 2018 8:34 pm

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.
Top
User avatar
Vader_Mester
Posts: 300
Joined: Tue Dec 05, 2017 8:28 pm
Location: Hungary
Contact:
Contact Vader_Mester

Re: What would you like to see in The Next Chip?

Postby Vader_Mester » Mon Jul 02, 2018 5:55 am

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.
There is multi tasking already!
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);
}
Top
ESP_Sprite
Posts: 9759
Joined: Thu Nov 26, 2015 4:08 am

Re: What would you like to see in The Next Chip?

Postby ESP_Sprite » Mon Jul 02, 2018 7:47 am

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.
Top
rogier
Posts: 1
Joined: Tue Jun 19, 2018 11:58 am

Re: What would you like to see in The Next Chip?

Postby rogier » Thu Jul 05, 2018 1:11 pm

A 9 data bit UART

For example for MDB:
https://www.namanow.org/images/pdfs/tec ... on_4-2.pdf
Top
michprev
Posts: 92
Joined: Fri Aug 04, 2017 8:57 pm

Re: What would you like to see in The Next Chip?

Postby michprev » Fri Jul 06, 2018 7:52 am

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
Top
Xarlan
Posts: 12
Joined: Tue Jul 10, 2018 3:09 pm

Re: What would you like to see in The Next Chip?

Postby Xarlan » Wed Jul 18, 2018 11:23 am

May be more friendly name of GPIO?
esp32_01.png
esp32_01.png (81.04 KiB) Viewed 14706 times
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
Top
ESP_Sprite
Posts: 9759
Joined: Thu Nov 26, 2015 4:08 am

Re: What would you like to see in The Next Chip?

Postby ESP_Sprite » Thu Jul 19, 2018 3:17 am

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.
Top
Post Reply

Return to “General Discussion”

Who is online

Users browsing this forum: audris and 99 guests