What about improve the functional pin mapping? Many boot strapping pins and other pins that used by on board flash makes it hard for pin arrangement. More confusing, SDIO even overlapped with bootstrapping pins and have different pull-up/down requirements for a 3.3v flash... Also, the exists of these pins makes it hard for using them in many general usages. If I connect it to SD card, it's fine to use internal pull-up after boot. But if I'm trying to use them to some other proposes, it's likely to cause booting problems...
And, if some of these pins are floating (I'm not sure if it's floating, but this issue happens on my nodemcu), it makes ESP32 hard to boot when plug-in to usb cable. And if you somehow touch or just connect a jump wire it become normal.
I think may be one EN pin or at most two pins to be used as boot pin is enough. Sending a special sequence after reset to determine all boot modes (serial-usb chip can take care of this) and move all other selection to efuse instead of exposing them to normal GPIOs to prevent boot strapping pin issues.
Also, if you don't like to use a larger package. In some packages like esp32-pico, considering connect flash pins internally in packages, leave them in the package and provide some extra IOs on the package instead of those hard to use SDIO pins so we can have more IOs in the same package size.
What would you like to see in The Next Chip?
Re: What would you like to see in The Next Chip?
more interface，like CAN
What I would like to see in the next IoT chip
Hi,
I would like to give my little contribution to the "What I would like to see in the next IoT chip" discussion.
This is my backgorund:
I've been designing boards with GSM/GPRS/3G modules and software drivers for 22 years.
I started to work in 1998 on the old Siemens M20 and I'm now working on the Gemalto EHS5 3G modem.
I've been working also for 2 years now on the ESP32 platform.
What I would like to see in the next IoT chip is:
1. Two cores with physically separated address spaces.
2. The first core will host the WiFi stack and an AT command interpreter able to work also in transparent mode in order to maximize the data throughput.
3. The second core will host the user's application program WITHOUT any kind of RTOS.
4. The 2 cores will be connected only by an internal USB interface at 12 MHz (Virtual COM)
or by a synchronous communication full duplex interface with DMA support.
5. All the common peripherals like ADC, SPI, I2S, UART, CSI et cetera will be mapped in the address space of the second core.
6. The first core will have a 5-stage pipeline with physically separated instruction and data buses (like ARM9 and ARM11).
7. The first and the second core will be licensed by ARM.
8. Windows native development tools.
Thanks,
Enrico Migliore
I would like to give my little contribution to the "What I would like to see in the next IoT chip" discussion.
This is my backgorund:
I've been designing boards with GSM/GPRS/3G modules and software drivers for 22 years.
I started to work in 1998 on the old Siemens M20 and I'm now working on the Gemalto EHS5 3G modem.
I've been working also for 2 years now on the ESP32 platform.
What I would like to see in the next IoT chip is:
1. Two cores with physically separated address spaces.
2. The first core will host the WiFi stack and an AT command interpreter able to work also in transparent mode in order to maximize the data throughput.
3. The second core will host the user's application program WITHOUT any kind of RTOS.
4. The 2 cores will be connected only by an internal USB interface at 12 MHz (Virtual COM)
or by a synchronous communication full duplex interface with DMA support.
5. All the common peripherals like ADC, SPI, I2S, UART, CSI et cetera will be mapped in the address space of the second core.
6. The first core will have a 5-stage pipeline with physically separated instruction and data buses (like ARM9 and ARM11).
7. The first and the second core will be licensed by ARM.
8. Windows native development tools.
Thanks,
Enrico Migliore
Re: What I would like to see in the next IoT chip
Hi,
I'll also would like to see:
9. Wettable flanks QFN package like Texas Instruments and NXP for easy automatice AOI inspection:
https://e2e.ti.com/blogs_/b/behind_the_ ... plications
https://e2e.ti.com/blogs_/b/behind_the_ ... ble-flanks
http://cache.freescale.com/files/traini ... -F0026.pdf
Unfortunately it's a patented package: https://patents.google.com/patent/US20120292755
10. A dedicated RESET pin
Thanks,
Enrico Migliore
I'll also would like to see:
9. Wettable flanks QFN package like Texas Instruments and NXP for easy automatice AOI inspection:
https://e2e.ti.com/blogs_/b/behind_the_ ... plications
https://e2e.ti.com/blogs_/b/behind_the_ ... ble-flanks
http://cache.freescale.com/files/traini ... -F0026.pdf
Unfortunately it's a patented package: https://patents.google.com/patent/US20120292755
10. A dedicated RESET pin
Thanks,
Enrico Migliore
-
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?
What strikes me in the ESP32 is the amount of computing power it has, but the lack of RAM.
I see that people are struggling with RAM amount on the chip, so 1MB RAM would be sufficient in the next chip, with a little bit bigger IRAM space, for insturction usage.
This would enable the user to store mure functions in IRAM, and use the RAM more extensively.
I see that people are struggling with RAM amount on the chip, so 1MB RAM would be sufficient in the next chip, with a little bit bigger IRAM space, for insturction usage.
This would enable the user to store mure functions in IRAM, and use the RAM more extensively.
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: 9764
- Joined: Thu Nov 26, 2015 4:08 am
Re: What would you like to see in The Next Chip?
yangff: Yes, we know the bootstrap mapping in the ESP32 is... suboptimal. We have learned from that, and the next chip should have the bootstraps on less conflicting pins. The idea to have internal pads to connect flash is a good one and it has ocurred to us before - expect this to turn up in the next chip as well.
wwwenrico: Don't count on that. We quite like the choice of a multitasking, multicore environment, and while separating cores makes sense for some things (e.g. security), it's not something we'll do just randomly. Especially internal USB makes no sense from a chip design perspective. What might help convince us is you stating what the reason is you architecturally need this specific setup and why an XTensa-based SMP setup cannot work in that scenario.
Vader_Mester: No promises on more RAM, although we're certainly looking at our options. (Issue is that RAM is relatively expensive; iirc, 3/4th of the silicon of the ESP32 is taken up by it.) FWIW, the next chip will allow the RAM to be partitioned more precisely, as in: of the RAM that is in the chip, the large majority of it can be configured as either IRAM or DRAM.
(Note: As usual, 'it will be in the next chip' is under the condition that our plans don't change last-minute.)
wwwenrico: Don't count on that. We quite like the choice of a multitasking, multicore environment, and while separating cores makes sense for some things (e.g. security), it's not something we'll do just randomly. Especially internal USB makes no sense from a chip design perspective. What might help convince us is you stating what the reason is you architecturally need this specific setup and why an XTensa-based SMP setup cannot work in that scenario.
Vader_Mester: No promises on more RAM, although we're certainly looking at our options. (Issue is that RAM is relatively expensive; iirc, 3/4th of the silicon of the ESP32 is taken up by it.) FWIW, the next chip will allow the RAM to be partitioned more precisely, as in: of the RAM that is in the chip, the large majority of it can be configured as either IRAM or DRAM.
(Note: As usual, 'it will be in the next chip' is under the condition that our plans don't change last-minute.)
-
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?
I thought that it's the case.ESP_Sprite wrote: Vader_Mester: No promises on more RAM, although we're certainly looking at our options. (Issue is that RAM is relatively expensive; iirc, 3/4th of the silicon of the ESP32 is taken up by it.) FWIW, the next chip will allow the RAM to be partitioned more precisely, as in: of the RAM that is in the chip, the large majority of it can be configured as either IRAM or DRAM.
Probably more pins might help solving the issue to be able to use external RAM on a parallel bus. Some STM32 models has this option, and used extensively.
The PSRAM is not the best option, since it uses up the precious SPI bus for flash reads.
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?
Maybe, dedicated pads for PSRAM.The PSRAM is not the best option, since it uses up the precious SPI bus for flash reads.
-
ESP_Sprite
- Posts: 9764
- Joined: Thu Nov 26, 2015 4:08 am
Re: What would you like to see in The Next Chip?
FWIW, the next chip in all probability is going to have a larger package (and thus more I/O) than the current ESP32.
Re: What would you like to see in The Next Chip?
What i want for the next chip is to send to some of us (the community) the first chips for beta testing/reviews 
Who is online
Users browsing this forum: No registered users and 64 guests