Features wish list

[cfaessler]

@daniel Cool thanks!

[cfaessler]

This post is deleted!

[Meide]

A 'read_timed' command as the one in the following link can be interesting:
http://docs.micropython.org/en/v1.8.6/pyboard/library/pyb.ADC.html

[mohpor]

@daniel
Currently, WiFi is initialized at boot (WiPy 2.0) and this feature cannot be disabled to be initialized later on (in boot.py) for example. I know it might be useful in some use cases, but it increases boot time and occupies memory and consumes battery power before we as developers get to disable it. I wish no extra features would be started before boot and we get to enable them as we wish, afterwards.

Cheers,
M.

[livius]

@mohpor
yes, somewhere someone wirite good point about this
i suppose that all features like wifi, blootooth, lora, ... should be disabled at start
maybe this can be achived by e.g. file existence on the flash.
like boot.config

if it does not exist - then all go same as is now
but if it exists then it should be parsed

[cfaessler]

Just read that the ESP32 shall have a built in Hall effect sensor and CAN bus Interface.
We needed both of it and used external peripherals until now. Is this something on your roadmap to implement?

[Colateral]

@daniel Wifi rssi() is important in IOT.

[livius]

@daniel
Will be good to have built in DTMF generator :)

[beyonlo]

@alexander said in Features wish list:

Direct hardware access (similar to the examples on Micropython speed), i.e. the Viper code emitter or some other approach to allow high speed digital IO

I agree.

[beyonlo]

@Roosted said in Features wish list:

@jasonriedy said in Features wish list:

• Enterprise WPA support

802.11X is the feature i'm really waiting for!
I've seen Wi-Fi marked as 'done' somewhere, but it is not usable in enterprise/educational environments...

For as far as I know 802.11X is supported in the ESP-IDF, so it would 'just' need to be implemented in python - right?

Thanks for steady development pace! :)

I think you are talking about 802.1x, correct?

Thanks.

[gertjanvanhethof]

@daniel One important feature to bring the xxPy devices to a higher enterprise ready plan is to add functionality to do firmware updates and software updates over-the-air.
Are there plans to add this?

[daniel]

@gertjanvanhethof yes, there are plans for this.

[Colateral]

@daniel BLE multipoint it is a MUST.

[beyonlo]

@Colateral said in Features wish list:

@daniel BLE multipoint it it MUST.

Yes, that is a very good feature.

[guy]

Must have:

• Encryption of login details on the module - currently I have to hard-code login details (eg. so WiFi on the LoPy can get in to my home network) in plain text. I imagine it's similar situation with any other login details on the device - unless I'm missing something? I can 1-way encrypt, but then can't use the encrypted details to log in to my wifi router.

Should have:

• Remotely update modules (firmware and scripts) via internet, and also suggest a best practice blueprint for doing updates offline (eg. via USB, SD and maybe even BT?)
• Number the pins on the module and the headers on the expansion board the same - very confusing currently

Nice to have:

• Some easy way for end-user to put their wifi login details on to the module (a good example is electric imp), ideally from mobile phone or USB.
• Possibly some way to kill threads when a script exists (currently they seem to linger)

[livius]

Will be good for developing to have option like save errors to flash
e.g. if we are connected to the board with UART then we can see errors like guru mediation printed.
But when we are not connected by UART we do not know what was the error message
and after reboot we lost any info

Will be good to have option e.g.

machine.SaveErrors=True

and it save errors to flash to file e.g. LastError.log

But i do not know if this is simple to accomplish and if any possible?

[BetterAuto]

@daniel said in Features wish list:

@gertjanvanhethof yes, there are plans for this.

Daniel does the team have a road map for OTA? Approximate timeline. In every new firmware announcement that's the first thing I look for :-)

I was grateful to see the WDT fix. Just in time.

Also I second the rssi request.

[RichardTXD]

@daniel
For me, I need 'survivability'. I really would like to know a crash has happened, the reason, and then be able to recoiver from it instead of going back to REPL.
Crashing is bad, non-recovery and not knowing what caused it is a lot worse.
For boards that are used remote and are really difficult to get back to update firmware etc - anything that makes them more reliable is a huge bonus.
Maybe a flag that causes reset on crash? Maybe more return-cause values from a reset? Maybe a stronger exception mechanism, a global one? Maybe a small list of functions that were executed prior to the crash that would help diagnose the fault?
Yes, I suspect that a crash may recur because the same code may be executed time and again. At least these options would allow some kind of diagnoastic later. PArticularly if the crash returned a list of functions that could be saved to SD on reset.
Thanks - Richard

[bucknall]

Hi @RichardTXD, you might want to check out the Watch Dog Timer, which is intended to help resolve the crashing issue you might be concerned with. https://docs.pycom.io/pycom_esp32/library/machine.WDT.html?highlight=watchdog

Let me know if this is what you're after!

[RichardTXD]

@bucknall
Hi and thanks for taking the time.
Yes and no. WDT on the same silicon is a-maybe but I prefer an external WDT. Same for Brown Out Detection (BOD). I think WDT has only just now become available. Not sure on BOD.
Silicon latchup is something I had to deal with on older CPUs and we tackled that by down powering and indeed it was the only way. Typically this happened at about the 0.6 volt VCC level - despite a 90 day run time on batteries, users let the product go flat - but they were an old CPU without BOD or a good POR etc.
I am still of the opinion it would be nice to know what caused a crash. A queue of function calls that can be unraveled and then used to get an idea of where a crash happened. We do this in a legacy product and store it in I2C for later. We'll probably implement that for our application at least during debugging.
Thank you for your attention - Richard