What would you like to see in The Next Chip?

[meowsqueak]

+ 802.15.4 hardware-assisted + software implementation for Zigbee / OpenThread / ...

Second this - support for 6LoWPAN specifically.

[Angel J.]

If 802.15.4 hardware is present, the 6LoPAN implementation is nothing more than software.

Unfortunately they have already replied that they will not include 802.15.4 hardware.

For the new low-power / low-speed mesh IoT networks WiFi-ah / 802.11ah would be the only option, as long as they include 900Mhz (Sub-GHz) RF hardware.

900Mhz has great advantages in IoT low consumption networks, is a frequency much more efficient than 2.4Ghz.

[EndlessDelirium]

There is little benefit in a new chip with an even broader feature set if Espressif keeps on failing to deliver on the SDK side. Take a closer look at the ESP32. The feature set of that chip already is rather awesome. But many of those features are either hard to use or simply broken.

So please do us the favor and invest into bugfixing/stabilizing/enhancing the ESP IDF and a new silicon revision instead.

[permal]

There is little benefit in a new chip with an even broader feature set if Espressif keeps on failing to deliver on the SDK side. Take a closer look at the ESP32. The feature set of that chip already is rather awesome. But many of those features are either hard to use or simply broken.

So please do us the favor and invest into bugfixing/stabilizing/enhancing the ESP IDF and a new silicon revision instead.

You have a point here, but I don't see improvement of IDF as mutually exclusive to a new chip. I'm fairly certain that they have stated previously in this thread that the idea is that the IDF will function also on the new chip. That said, I too would like to see the IDF on the ESP32 feature complete and stable before a new chip, though I wouldn't go as far as saying they have failed to deliver - it does work once you understand the limitations and thought behind the APIs.

IMHO, it is the lack of detailed documentation that is hurting IDF, not the implementation. Also, the code examples misses their mark - instead of showing how to use the APIs, including limitations and quirks etc., they show an implementation of a hardware interface for some specific hardware, thereby forcing the reader to sort out what parts of the code actually concerns the API and what parts that are only related to the specific hardware. The example for the RMT is a prime example of this imho. (I've not read through all the examples, so this may be biased, but it is my perception of things).

[BuddyCasino]

IMHO, it is the lack of detailed documentation that is hurting IDF, not the implementation. Also, the code examples misses their mark - instead of showing how to use the APIs, including limitations and quirks etc., they show an implementation of a hardware interface for some specific hardware, thereby forcing the reader to sort out what parts of the code actually concerns the API and what parts that are only related to the specific hardware. The example for the RMT is a prime example of this imho. (I've not read through all the examples, so this may be biased, but it is my perception of things).

That is true. I sometimes have the impression that the software guys (which I think are very talented) don't have the required information how certain edge cases work, so maybe there is a communication problem between hw and sw departments?

It is constantly improving though, and lets not forget its a huge task. There is a lot of work going on that is not very visible (like pSRAM support), and Espressif is a small company. Good thing this forum exists for getting help.

[meowsqueak]

If 802.15.4 hardware is present, the 6LoPAN implementation is nothing more than software.

Unfortunately they have already replied that they will not include 802.15.4 hardware.

For the new low-power / low-speed mesh IoT networks WiFi-ah / 802.11ah would be the only option, as long as they include 900Mhz (Sub-GHz) RF hardware.

900Mhz has great advantages in IoT low consumption networks, is a frequency much more efficient than 2.4Ghz.

Lack of 802.15.4 hardware would be a great shame, as the power consumption of WiFi is way too high for many IoT applications, even with long "sleeps". But as you say, if a suitable alternative low-power mesh network interface is provided, then it would go a long way to help. If I reword my suggestion then I'm really just suggesting low-power mesh network hardware of some sort.

[ESP_Sprite]

meowsqueak: We will have a mesh solution; from what I hear it should also be pretty low-power, but I don't know the details.
EndlessDelirium: The SDK and new silicon are parallel developments. We could serialize them, but I'm not sure if you want a SDK that is partially written by hardware developers and analog guys/gals...

[grooves]

I would like to have a faster wifi connection after deep sleep reboot,
which is essential for battery powered applications
Right now it takes about ~0,2 sec to connect to an open AP, and ~1.0 sec to an WPA2 secured AP.
setup with static IP and stopped DHCP

Grooves

[halfro]

1. Well radio implementations such as LORA for LPWAN, nothing more than that for in my side of the world(Kenya). It can even be an off chip addition that can be done as a module that one can buy in bulk from a single supplier. I have done deployments for such and the ESP32 is a real contender if this was taken up. The advantage is actually obtaining this from a single supplier.

2. The ability to get the WROOM32 with a uFL connector that one can add an eternal antenna in the case where one is using a product case.

[loboris]

1. Well radio implementations such as LORA for LPWAN, nothing more than that for in my side of the world(Kenya). It can even be an off chip addition that can be done as a module that one can buy in bulk from a single supplier. I have done deployments for such and the ESP32 is a real contender if this was taken up. The advantage is actually obtaining this from a single supplier.

2. The ability to get the WROOM32 with a uFL connector that one can add an eternal antenna in the case where one is using a product case.

If nothing else, than you already have such a board and module satisfying both of your requirements:
Pycom's LoPy (specs)
L01 OEM module (specs)