What would you like to see in The Next Chip?
Re: What would you like to see in The Next Chip?
I agree with some of the common suggestions that I've seen
* USB (Can it be OTG?)
* 5Ghz
I'd also like to see some lower frequency support. Even if it's wifi on 900mhz. Although something akin to the CC1100 would be nice too. At the same time, I'm sure RF stuff on a chip is much harder to pull off than not so I won't hold my breath on that.
Thanks to whoever shared the die shot. I assume the large area there is mostly ram. That was a little shocking how big that area is compared to what I assume the processing area is. It'd be nice to see an annotated version someday.
I might be too much of a newbie to ask, but is it possible to load a binary into RAM and execute it rather than flashing it first?
* USB (Can it be OTG?)
* 5Ghz
I'd also like to see some lower frequency support. Even if it's wifi on 900mhz. Although something akin to the CC1100 would be nice too. At the same time, I'm sure RF stuff on a chip is much harder to pull off than not so I won't hold my breath on that.
Thanks to whoever shared the die shot. I assume the large area there is mostly ram. That was a little shocking how big that area is compared to what I assume the processing area is. It'd be nice to see an annotated version someday.
I might be too much of a newbie to ask, but is it possible to load a binary into RAM and execute it rather than flashing it first?
Re: What would you like to see in The Next Chip?
An 802.15.4 MAC capable of supporting Zigbee/OpenThread, with a suitable WiFi/BLE/15.4 coexistance mechanism.
-
- Posts: 9757
- Joined: Thu Nov 26, 2015 4:08 am
Re: What would you like to see in The Next Chip?
Doc Oct: The USB we're planning to integrate will indeed be OTG, however don't expect anything fast (most likely FS/LS-only) in the next chip. Lower freq support and other protocols: we hear you, but at the moment I have nothing specifically to say about that.
Also, loading a binary into RAM is a software question, but I can already answer it: yes, it's possible, even with the current esptool. However, as esp-idf binaries tend to be rather large and not fit into RAM directly, there's no real fleshed-out support for this. But you could possibly pull it off by stripping your program to a minimum and writing custom ld scripts.
Also, loading a binary into RAM is a software question, but I can already answer it: yes, it's possible, even with the current esptool. However, as esp-idf binaries tend to be rather large and not fit into RAM directly, there's no real fleshed-out support for this. But you could possibly pull it off by stripping your program to a minimum and writing custom ld scripts.
Re: What would you like to see in The Next Chip?
I guess what I myself would want by far the most is more pins (QFN is fine, but a 0.8 mm ball pitch BGA would be even better). I have a few designs which I would like to use the ESP32 in, but the low pin count is a pain for me. I would love to have an extra 10 I/O if not more, and am fine with paying $1 more per IC even for that privilege. I cannot use an I/O expander because it would be too slow. The I2S parallel output is great but it gets very tight when a decent chunk of I/O is used for SPI Flash, programming pins, etc.
The ESP32 IC is great in terms of bang for buck, even when not considering being used in IOT applications. The SDK is great and very active, and I extremely applaud the CMake efforts (can't wait till the python2 dependency for gen_esp32part.py is dropped). Also how well it is paired with FreeRTOS. It is a bummer that the radio stack isn't sufficiently accessible such that other RTOS's like ChibiOS or Nuttx can be ported.
Also I am very much not a fan of the debugging situation, where it's pretty much just printf's over the RX/TX pins. I am used to using Segger with Cortex-M devices, where the interface is very quick for flashing. Also then being able to use great tools like Seggers RTT for dumping a few MB/s to my desktop while using SystemView/Ozone for debugging is incredible.
Going further, it's very sad that the LX6 core is used. I understand not wanting Cortex-M since Espressif is so cost conscious for these IC's, but then why not go with RISC-V? That way we can make use of the LLVM/Clang stack and do incredible things like this: https://www.youtube.com/watch?v=VKIv_Bkp4pk and make use of modern C++17 and beyond. Instead of having to rely on GCC.
The ESP32 IC is great in terms of bang for buck, even when not considering being used in IOT applications. The SDK is great and very active, and I extremely applaud the CMake efforts (can't wait till the python2 dependency for gen_esp32part.py is dropped). Also how well it is paired with FreeRTOS. It is a bummer that the radio stack isn't sufficiently accessible such that other RTOS's like ChibiOS or Nuttx can be ported.
Also I am very much not a fan of the debugging situation, where it's pretty much just printf's over the RX/TX pins. I am used to using Segger with Cortex-M devices, where the interface is very quick for flashing. Also then being able to use great tools like Seggers RTT for dumping a few MB/s to my desktop while using SystemView/Ozone for debugging is incredible.
Going further, it's very sad that the LX6 core is used. I understand not wanting Cortex-M since Espressif is so cost conscious for these IC's, but then why not go with RISC-V? That way we can make use of the LLVM/Clang stack and do incredible things like this: https://www.youtube.com/watch?v=VKIv_Bkp4pk and make use of modern C++17 and beyond. Instead of having to rely on GCC.
-
- Posts: 9757
- Joined: Thu Nov 26, 2015 4:08 am
Re: What would you like to see in The Next Chip?
FWIW: Multiple GPIOs is often-heard, and we will have more of them for the next chip. RiscV is also often-heard; do notice that the development of RiscV has gone at a breakneck speed the last few years while chip-development usually is a bit slower, so for the ESP32 there was no chance of a RiscV core. We're dipping our toes in the water, however (note Espressif is a member of the RiscV foundation) because we certainly see the advantage of the ISA. A small physical token of this intention will hopefully appear in the immediate next chip. Similarily with LLVM: we do see the advantages of having support of this toolchain for the ESP32 and other chips and we're actually actively working on steps to make this happen.
- leandro.adonis86
- Posts: 5
- Joined: Sun Jul 01, 2018 10:19 pm
- Location: Portugal - Leiria
Re: What would you like to see in The Next Chip?
A must and perfect ESP32 would be nice to have BLE 5.0 and IEEE 802.15.4 support, wifi 5G can come later. Thank you.
Student of Computer Engineering from Polytechnic Institute of Leiria - Portugal
Re: What would you like to see in The Next Chip?
WIFI+BLE+GPRS+GPS would be great!
Re: What would you like to see in The Next Chip?
for example to realize usb-sniffer.(how much EPs did you have in mind, by the way, and did you have a specific purpose in mind?
Is it possible to reduce power consuption?
The support 802.15.4 also will be nice.ESP32: Transmit BT/BLE, POUT = 0 dBm - 130 - mA
nRF52832: TX only run current PRF = 0dBm 11.6 mA
ESP_Sprite
thank you for your answer!
-
- Posts: 48
- Joined: Mon Apr 30, 2018 5:32 pm
Re: What would you like to see in The Next Chip?
- I think that having a ports that could drive 1A or more would be awesome
- Sleep power modes that have WOR (Wake On Radio) feature. (beside other waking functions)
- Sleep power modes that have WOR (Wake On Radio) feature. (beside other waking functions)
- martinayotte
- Posts: 141
- Joined: Fri Nov 13, 2015 4:27 pm
Re: What would you like to see in The Next Chip?
No MCU or SoC around the world can provide 1A on GPIOs ! It is up to you to add some MOSFET to drive such current ...Adham Aboud wrote:- I think that having a ports that could drive 1A or more would be awesome
WOR can not be achieve without having the radio not sleeping ...Adham Aboud wrote:- Sleep power modes that have WOR (Wake On Radio) feature. (beside other waking functions)
Who is online
Users browsing this forum: No registered users and 306 guests