ESP8266 Developer Zone

Re: New FEATURES gathering

2019-01-25T17:11:20+08:00

"Boost" mode in ESP8266 where the CPU or base clock is doubled (I know the CPU can do it) and WLAN is temporary suspended.

Statistics: Posted by eriksl — Fri Jan 25, 2019 5:11 pm

Re: New FEATURES gathering

2019-01-25T17:10:17+08:00

That's already in ESP32?

Statistics: Posted by eriksl — Fri Jan 25, 2019 5:10 pm

Re: New FEATURES gathering

2019-01-29T15:24:08+08:00

Hardware I2C PLEASE (ESP8266)!

Statistics: Posted by alex323qp — Fri Jan 25, 2019 3:22 pm

Re: New FEATURES gathering

2017-11-29T00:24:34+08:00

TuanPM wrote:
Mesh network

I second that. It will be very nice and useful if mesh is properly integrated into the main SDK in one of the future release!

Statistics: Posted by iia — Wed Nov 29, 2017 12:24 am

Re: New FEATURES gathering

2017-07-27T01:06:03+08:00

having precise receiver time stamp through Time of Arrival(via multi-path Channel State Information) surely helps a lot for indoor localisation applications. does your latest ESP8266 SDK already supports this feature? if yes, how can i get access to that? kindly guide me regarding this

Statistics: Posted by Hemamali — Thu Jul 27, 2017 1:06 am

Re: New FEATURES gathering

2016-12-07T18:11:29+08:00

I hope support more GPIO, we can use a group of GPIO as switch to config MESH_GPIO_ID flexible by consumer , otherwise we need a extra GPIO chip for this purpose.

another more UART is right.

Statistics: Posted by mtv — Wed Dec 07, 2016 6:11 pm

Re: New FEATURES gathering

2016-08-04T13:43:57+08:00

25KHz PWM. In some application, e.g. DC motor driving, PWM may cause accoustic nose. A simple solution is to use PWM with the frequency around 25KHz. As pwm resolution has been 45ns, that means it is complete feasable to upgrade PWM frequency to 25KHz with the resolution better than 512; I have noticed a request for this at least 1 year ago. I wish we could soon find that in esp8266 bot NONOS and RTOS SDK (at least RTOS version) and be ready in ESP32 SDK when it is available.

Thans and Regards

Statistics: Posted by sportybj — Thu Aug 04, 2016 1:43 pm

Re: New FEATURES gathering

2016-07-13T07:00:32+08:00

I would definitely appreciate hardware PWM support. It is a real struggle to implement LED dimming or motor control without it.

Statistics: Posted by albru123 — Wed Jul 13, 2016 7:00 am

Re: New FEATURES gathering

2016-07-07T09:41:30+08:00

信号中继，可以当做信号放大器用

Statistics: Posted by loveme758 — Thu Jul 07, 2016 9:41 am

Re: New FEATURES gathering - LWM2M support on SDK

2016-06-29T20:20:15+08:00

I would like to have support for this standard in my iot gadgets:

https://en.wikipedia.org/wiki/OMA_LWM2M
http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/oma-lightweightm2m-v1-0

An open source c++ library for it was already have been released, so it is a matter of integrate it with Espressif SDK ...
https://github.com/eclipse/wakaama

Statistics: Posted by chrishawk — Wed Jun 29, 2016 8:20 pm

Re: New FEATURES gathering

2016-05-11T06:06:05+08:00

Would you please consider adding some better DSP capability in the CPU eg:

In the "4.1Overview of Options" of the "Xtensa Instruction Set Architecture (ISA) Reference Manual" (http://0x04.net/~mwk/doc/xtensa.pdf) are listed some options that support DSP. Would you please consider adding the following (if not already included):

1. 32-bit Integer Multiply Option
2. 32-bit Integer Divide Option
3. MAC16 Option

Being able to do some DSP on sensor data before it is sent will open up options of acting locally, customizing the processing for each location or sensor, as well as reducing bandwidth requirements. This would enable systems to be better able to be scaled up. That is, as the system grows so does its processing ability. The upstream load, as the system is scaled up, is less dependent on system size enabling a more flexible system.

If these options could be added while maintaining the low cost of your product, I believe this would increase your products appeal.

Regards
Geoff

Statistics: Posted by GeoffL — Wed May 11, 2016 6:06 am

Re: New FEATURES gathering

2016-05-04T03:26:24+08:00

I believe there should be an alternative provisioning/wifi password setting method that works with a smartphone. What about NFC, sound (modulating wifi password as CW or AM and playing it on the speaker,) or using a PCB trace as an induction coil to catch signal directly from the speaker coil?

Statistics: Posted by Paul — Wed May 04, 2016 3:26 am

Re: New FEATURES gathering

2016-03-12T18:19:28+08:00

How about increasing the limit of no. of stations that can connect to one SoftAP?

Statistics: Posted by Guest — Sat Mar 12, 2016 6:19 pm

Re: New FEATURES gathering

2016-03-03T02:21:17+08:00

Hi Espressif,

1 - Smartconfig capable to send some more information like: IP, mask, dns, gateway and small user buffer (+- 32bytes)
2 - NTP suport

Thanks

Statistics: Posted by ivanroberto — Thu Mar 03, 2016 2:21 am

10 first ideas to cross my mind

2016-02-02T07:21:27+08:00

1: homeplug
since wifi is 2400-2489MHz and homeplug <87Mhz (hpgp <30Mhz) maby some sort of direct connection to the dac/adc without tuning.

2: radio clock reciver 25khz-25mhz (maby using same hack as homeplug)

3: qam/dvb-c/dvb-t/atcs tv transmission on channels 40-88Mhz (maby using same hack as homeplug)

4: smaller cheaper low pin count versions (like attiny) 8-16pin smd with diameter less than aaa sized batteries

5: onchip e-mram (for unified flash/ram) and maby smaller size or more memory

6: extra spi (use & boot from spi without touching sdio pins) or extra sdio

7: dac/adc mux on all gpio pins

8: ethernet support (over gpios w/hw accel)

9: bluetooth LE (if not included in bluetooth4)

10: 0-6500Mhz tuneable (for dab/drm/dvb-h+t2+c2+s2x/atcs/gsm/cdma/lte/satphone/2,5ghz-wifi/5ghz-wifi/wimax/etc..)

+ samples/demos/schematics/tutorials

Statistics: Posted by pax — Tue Feb 02, 2016 7:21 am

Re: New FEATURES gathering

2016-01-06T00:40:19+08:00

Bluetooth integration...

Statistics: Posted by gaeliz — Wed Jan 06, 2016 12:40 am

Re: New FEATURES gathering

2015-12-30T16:09:00+08:00

分裂为两条路线去发展，或者更简洁，或者更全能。
1.去掉CPU，串口等和WIFI无关的硬件部分，减少芯片面积，减少IO口，只能通过SPI接口被主控处理器驱动，使得芯片更简洁更可靠，功耗更低，成本更低。并提供一个官方的驱动库，其他和WiFi无关的软件硬件部分都由产品研发人员自己解决，我想这个会非常受欢迎的。
2.增强CPU能力，增加IO口数量，增加各种外设资源，增加RAM，最好把Flash也都集成进去，这样对很大一部分的应用可以实现单芯片解决。

Statistics: Posted by scilogyhunter — Wed Dec 30, 2015 4:09 pm

Re: New FEATURES gathering

2015-12-20T07:04:39+08:00

Access to entire packets (including radio tap header containing RSSI information added by NIC) would be nice.

Statistics: Posted by prismatics — Sun Dec 20, 2015 7:04 am

Re: New FEATURES gathering

2015-12-07T20:53:47+08:00

eriksl wrote:
chaeplin wrote:- a api to prevent connecting to OPEN AP
- a api to get the encryption type of the current network

Both are already available, check the docs

Oh ? I can't find at SDK 1.5.

Can you tell the encryption type of the current connected AP without scan ?
Can you prevent connecting to OPEN AP when wake up ?

Ref: https://www.arduino.cc/en/Reference/WiFiEncryptionType

Statistics: Posted by chaeplin — Mon Dec 07, 2015 8:53 pm

Re: New FEATURES gathering

2015-12-06T17:35:14+08:00

Urgent request: IRAM usage.

I doing my ***** best to keep IRAM usage low. I've come to the point where I have 213 k of IROM code, almost everything I make is in IROM, unless really really necessary in IRAM. I now have 500 bytes of IRAM left. I upgraded to 1.5.0 and now it's only 150 bytes. My code only uses a few hundred bytes of IRAM, the rest is all libraries, most of them SDK libs.

So there is not really much left I can optimise. That would be a shame, because I have lots of IROM (flash) left, it would be a pity if I couldn't use it because IRAM is already completely filled up.

So a really urgent call from me to Espressif to try to optimise the code to take up less IRAM, please!

Maybe the crypto was formerly compiled to IROM and as external lib now is IRAM?

Statistics: Posted by eriksl — Sun Dec 06, 2015 5:35 pm

Re: New FEATURES gathering

2015-12-06T17:28:57+08:00

My requests: PWM enhancement.

The current software PWM implementation does a decent job, it's usable, but it looks like it hasn't been finished. To make it really comparable to a hardware implementation we're used to please add:

- Dynamic membership of a GPIO (i.e. user can make GPIO a PWM or a normal GPIO after user started the PWM subsystem)
- Implement 100% on and 100% off for PWM GPIO's. I think this could be added quite simply by making the GPIO a normal GPIO if 0% or 100% is detected and then staticly setting the GPIO off or on. That's what I do on AVR's at least, works quite well When the duty is changed, make the GPIO PWM again. I guess for that to work my first enhancement request should also be implemented
- Implement glitch-free frequency-correct PWM (not for me personally, but for the user that use PWM to drive motors); i.e. make the counter go up, then bounce, go down, bounce and go up again, so the duty is cycle is mirrored and the effective PWM frequency is divided by two.

The current state of PWM makes a lot of users not using it and trying to create their own using hardware interrupts (which is more or less prone to fail anyway, because apparently the non-maskable interrupt is used not only for PWM).

Statistics: Posted by eriksl — Sun Dec 06, 2015 5:28 pm

Re: New FEATURES gathering

2015-12-06T17:16:51+08:00

chaeplin wrote:
- a api to prevent connecting to OPEN AP
- a api to get the encryption type of the current network

Both are already available, check the docs

Statistics: Posted by eriksl — Sun Dec 06, 2015 5:16 pm

Re: New FEATURES gathering

2015-12-06T17:16:06+08:00

geo.espressif wrote:
An snprintf implementation would help a lot.

Yes agree, but completely in ROM not in RAM!

Statistics: Posted by eriksl — Sun Dec 06, 2015 5:16 pm

Re: New FEATURES gathering

2015-12-06T17:15:07+08:00

MikeBolton wrote:
I know it has been mentioned before (many times) but could I ask again for an alternative to the (very outdated) AT command set.
If the ESP is to be interfaced with any reasonable microcontroller, it needs a simple, fast, binary scheme, preferably via the SPI as this can be faster with a MCU than a USART. Instead of the long winded AT commands, can we have single byte instructions (255 possibles) and no ASCII except for 'strings'. Also I see no point in having a very fast WiFi if you can only get the info in and out very slowly !

Agreed.

But even better, just dump the whole standard software and create your own binary interface

Statistics: Posted by eriksl — Sun Dec 06, 2015 5:15 pm

Re: New FEATURES gathering

2015-12-02T18:06:09+08:00

- a api to prevent connecting to OPEN AP
- a api to get the encryption type of the current network

Statistics: Posted by chaeplin — Wed Dec 02, 2015 6:06 pm

Re: New FEATURES gathering

2015-11-27T23:33:20+08:00

An snprintf implementation would help a lot.

Statistics: Posted by geo.espressif — Fri Nov 27, 2015 11:33 pm

Re: New FEATURES gathering

2015-11-09T04:44:33+08:00

I know it has been mentioned before (many times) but could I ask again for an alternative to the (very outdated) AT command set.
If the ESP is to be interfaced with any reasonable microcontroller, it needs a simple, fast, binary scheme, preferably via the SPI as this can be faster with a MCU than a USART. Instead of the long winded AT commands, can we have single byte instructions (255 possibles) and no ASCII except for 'strings'. Also I see no point in having a very fast WiFi if you can only get the info in and out very slowly !

Clearly the links into the SDK must be there so a 'simple' data transfer scheme should be fairly easy.

Mike Bolton

Statistics: Posted by MikeBolton — Mon Nov 09, 2015 4:44 am

Re: New FEATURES gathering

2015-11-03T22:58:12+08:00

Hi,
how about real time clock?

Statistics: Posted by idragoev — Tue Nov 03, 2015 10:58 pm

Re: New FEATURES gathering

2015-10-30T10:36:58+08:00

Hi espressif stuff,

i append my wishes :

real, unchangeable, permanent Chip uid -

txs

best wishes
rudi

Statistics: Posted by rudi — Fri Oct 30, 2015 10:36 am

Re: New FEATURES gathering

2015-10-15T16:02:59+08:00

I vote against 5V tolerance. 5V is hopelessly outdated and obsolete. Just run everything on 3.3V and you're fine.

Statistics: Posted by eriksl — Thu Oct 15, 2015 4:02 pm

Re: New FEATURES gathering

2015-10-06T05:51:50+08:00

Hi Espressif team,

Great job, I do appreciate the work done so far!
Some suggestions and observations;

3V3 LDO could be integrated into the chip with at least 300mA capability and wide input voltage range
just like TOREX XC6206
http://www.torexsemi.com/products/detail.php?id=368
All IOs should be 5V tolerant for better IOP with other hardware

and

finally, more ADC channels with 12 bit or higher resolution

Thanks,

Keep up the good work

Statistics: Posted by javed — Tue Oct 06, 2015 5:51 am

Re: New FEATURES gathering

2015-10-03T03:27:57+08:00

Overall so far we feel good about ESP8266 and it's s/w. But few things come to mind:

HW:

- can we have 64 bit timer for deep sleep? current 32-bit usec timer is only slight over 1 hour sleep time.

SW:

- please open up source code for your lib. especially those seems (?) to be somehow connected to severs at ESPRESSIF. E.g. OTA functions and IoT functions. Those lib should be made such that users can configure their own servers.

- for smartconfig, there are some security concern discussions on how TI does it. Again, it would be better if source code is available so users can see how it's implemented here.

- we are using setup similar to NodeMCU where there is an external push button to reset/wake up the chip. But it share the same reset pin with deep sleep. When it wakes up from deep sleep, s/w does not seem to tell if it's awaken by push button or timer expires. Can the s/w be modified to read the timer to see if it's really expired and add a new "External_Wakeup" reset code so user can tell exactly why it's awaken?

Thanks!!

-

Statistics: Posted by derekh — Sat Oct 03, 2015 3:27 am

Re: New FEATURES gathering

2015-09-22T22:42:42+08:00

A 'built-in' Bonjour / Zeroconf' capability. This is essential if the ESP is ever to be used as a standalone service provider. This seems a very obvious requirement for any IoT device but a glaring omission on the ESP?

Statistics: Posted by MikeBolton — Tue Sep 22, 2015 10:42 pm

Re: New FEATURES gathering

2015-08-04T12:20:48+08:00

IP-level packet operation API

Statistics: Posted by vvvictor — Tue Aug 04, 2015 12:20 pm

Re: New FEATURES gathering

2015-08-02T16:48:11+08:00

real i2c hardware
more, much more iram (not because I need it but because libraries need it)
normal libc api, even the at atmel attiny 25 has it (2k flash, 256 bytes ram...) I mean e.g. a normal snprintf implementation, not a crippled one with a strange name, likewise for all the other functions. I assume with more iram it will be possible to use a normal embedded libc.
PROPER PROTOTYPES for ALL sdk functions.
proper hardware pwm

Statistics: Posted by eriksl — Sun Aug 02, 2015 4:48 pm

Re: New FEATURES gathering

2015-07-30T22:55:35+08:00

BLE support
=======
for example we can to use
user1 - WiFi
user2 - BLE
---------
(want to exclude BT module from the BOM )

Statistics: Posted by AlOdin — Thu Jul 30, 2015 10:55 pm

Re: New FEATURES gathering

2015-07-20T21:18:01+08:00

Not sure if this is already implemented or not. Couldn't find anything like it in the documentation.

I would like the following features (several possible subsets would solve most of my current problems):

A way to enable and disable WiFi in software without resetting the chip. (Transition WAKE_RF_DISABLED<->WAKE_RF_DEFAULT states without requiring a deepSleep cycle which resets the processor.
A way to set up a callback function to restart after deepSleep and a flag to allow deepSleep to keep the RAM contents
More RAM

Beyond those basics that would be really handy for my low-power sensor platform work, I'd also like IPv6 so I can talk to the modern internet instead of needing a gateway or translator. This one is actually critical and may prevent me from continuing to use the chipset if it isn't resolved soon.

5Ghz 802.11ac would be nice.

BETTER DOCUMENTATION, especially for the Arduiino IDE.

The secret decoder ring for messages displayed at boot time.

Statistics: Posted by owendelong — Mon Jul 20, 2015 9:18 pm

Re: New FEATURES gathering

2015-05-27T01:33:24+08:00

As bootloader keep changing with SDK releases, can you enable FOTA bootloader upgrade ? Same mechanism as user1.bin, user2.bin upgrade I suggest having a backup partition for boot.bin at 0x80000 (currently reserved sector) and SDK jumps on the valid bootloader at 0x0 or 0x80000.

thanks

Statistics: Posted by Guest — Wed May 27, 2015 1:33 am

Re: New FEATURES gathering

2015-05-12T07:18:45+08:00

free parcel with
fully basic starter kit from espressif
for all registered board forum developer

with the newest ESP???? chip and all the new features that was done by listing

best wishes
rudi

i will be a beta tester
yes ..please add me to the list

Statistics: Posted by rudi — Tue May 12, 2015 7:18 am

Integrated power supply controller.

2015-04-28T03:37:46+08:00

In order to reduce chip count in high volume applications, consider integrating a power supply controller. In my case I need a hot ground power supply. The common chip for doing this is a Power Integrations LNK302 or LNK304. Datasheet: http://ac-dc.power.com/design-support/p ... ata-sheet/ The LN302 integrates the needed FET, but with the ESP-type chips you might want to use an external FET to provide more flexibility. Change the FET to increase the current output.

An ideal integrated power supply controller would be flexible to do all of this....
1) Hot ground constant voltage supply - use case: dimmers, outlets
2) Hot ground constant current supply - use case: LED bulbs
3) Buck-boost supply - batteries

Once the power supply controller is integrated it becomes possible to add some extreme 'Green' features to the chip. For example - when the chip is ready to use wifi it could instruct the power supply controller to fully charge up the output capacitor. When in deep sleep it could be smart enough to only charge the output cap once every 50 cycles. This helps solve one of the main problems with smart LED light bulbs - they draw too much power when they are off. Under IEC62301 if standby power is 5mW of less, you can advertise it as Zero power consumption in the EU. This may be achievable with an integrated power supply controller.

Statistics: Posted by jonsmirl — Tue Apr 28, 2015 3:37 am

Two 12-bit ADC with PGA

2015-04-28T03:22:00+08:00

At least two 12-bit ADC channels with a programmable amplifier (PGA) in front of them. Check out the datasheet for the Atmel 90E21.
http://www.atmel.com/Images/Atmel-Meter ... g_0402.pdf

These two ADC channels can be used for any purpose, but my specific use is for power consumption monitoring. For example - an AC outlet that monitors how much power is being used. Outlets like this are used in data centers to bill people for the power they use. They would also be used in home automation if they were cheaper, adding the ADC+PGA would make them cheap enough. Note that you have to be able to simultaneously sample the two ADCs in order to do the calculations, you can't have one ADC and switch inputs between it.

Statistics: Posted by jonsmirl — Tue Apr 28, 2015 3:22 am

Re: New FEATURES gathering

2015-04-16T15:20:10+08:00

With a new chip, 5V tolerant I/O-pins would definitely be welcome.

Statistics: Posted by spiff — Thu Apr 16, 2015 3:20 pm

Re: New FEATURES gathering

2015-04-10T17:09:46+08:00

1 HTTP配置和升级
希望能有一个HTTP的WEB配置界面,能很方便的配置WIFI模块的大部分参数.WEB界面中最好有程序更新功能(尽管有了云升级功能).

2 模块能否支持中继
在部分三室一厅里,路由器功率小,不能覆盖每隔角落, WIFI模块能否支持自动中继功能来弥补这个问题.

暂时就这些,ESP8266 是一块很强大的WIFI芯片.

谢谢.

Statistics: Posted by huafan — Fri Apr 10, 2015 5:09 pm

Re: New FEATURES gathering

2015-04-10T01:39:48+08:00

DMA engine with few channels, triggers linked to wifi/uart/spi/i2s... peripherals (to be able to configure a simple "data pump" from wifi to spi or i2s etc)

Statistics: Posted by mculibrk — Fri Apr 10, 2015 1:39 am

Re: New FEATURES gathering

2015-04-10T01:32:48+08:00

costaud wrote:
How about Uart and SPI port, what kind of interrupt event do you want ??

It would be very nice to have some sort of "threshold" for generating the SPI (or other UART...) interrupts.

Interrupts are now triggered only on completion of some action - for example int on end transfer.

What I mean is to have some way of configuring the interrupt to trigger before the entire fifo/buffer is processed.

Why? If you need to have a "constant" output stream (on SPI or UART) you should start filling (or reading) the fifo before the end of transmission/reception otherwise there will always be gaps - after the interrupt triggers you need time to re-fill the fifo and start a new transfer.

regards

Statistics: Posted by mculibrk — Fri Apr 10, 2015 1:32 am

Re: New FEATURES gathering

2015-04-10T01:31:01+08:00

Publish source for all the blobs --- or at least the wifi / 80211 ones so at least we can figure out what is going on

Statistics: Posted by cortinas — Fri Apr 10, 2015 1:31 am

Re: New FEATURES gathering

2015-04-06T20:10:47+08:00

Support for packet injection on 802.11

Statistics: Posted by israellot — Mon Apr 06, 2015 8:10 pm

Re: New FEATURES gathering

2015-04-05T00:24:08+08:00

The new AT commands v0.23 seems to be stable enough, but we still need SSL connection AT command.
Custom upgrade command was a great addition I didn't try it yet...
Thanks!

Statistics: Posted by SL!M — Sun Apr 05, 2015 12:24 am

Re: New FEATURES gathering

2015-02-16T09:24:21+08:00

Support the FreeRTOS SDK, it's so much better than the std SDK!

Statistics: Posted by tve — Mon Feb 16, 2015 9:24 am

Re: New FEATURES gathering

2015-02-13T18:25:16+08:00

Hello, I think a very important feature is to be able to define your own update server, it would make our lives lot easier

Statistics: Posted by SL!M — Fri Feb 13, 2015 6:25 pm