Features wish list

[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

[robert-hh]

@daniel For the good of all of us who re-flash frequently:

• a jumper on the Expansion Board to connect GPIO0 (G23) and GND, or the two transistor logic that makes use of the logic of esptool.py for firmware flashing (see wemos D1, Huzzah feather, ...).

[daniel]

@robert-hh we are doing better than that. There will be an auto-program logic that won't require a jumper. This functionality is also possible on Pytrack/Pysense and we will enable it shortly.

[redimo]

@daniel How far are you with the:
bluetooth.get_adv() returns a list of all received advertisements in the FIFO instead of just one.
?

We are experiencing problems were 2 WiPy 2.0 can be next to each other, but one will NEVER find anything at all whilst the other is constantly reporting found ADVs. Is there any fix for this or schedule? Its kinda worrysome as we've been having this issue for Months and have yet to receive anything from you, even after having e-mail contact with your devs.

[daniel]

@redimo sorry about that. Please explain what is your feature request... You want get_adv() to return a list instead of just one, correct?

Also, that problem that you describe with the 2 WiPy's can you elaborate more? Thanks.

[redimo]

@daniel This is our Code:

from network import Bluetooth
import binascii
import dataStore

class bluetooth:
data = dataStore.DataStore ()
bluetooth = Bluetooth()
bluetooth.init()

def __init__(self,data,):
    #Init Bluetooth and enable Scanning
    self.data = data 
    if not self.bluetooth.isscanning():
        self.bluetooth.start_scan(-1)
  

def scan(self):
    adv =self.bluetooth.get_adv()       
    try: 
        #look if the receved mac is in the data store
         for x in range(0, (self.data.getAnzahlTokens())):                
            if str(binascii.hexlify(adv.mac)) == str(self.data.getnextMac()): 
                    #lay down the RSSI value to the DataStore
                    print('*********************************************')
                    print("Geraete Mac Adresse = {}".format(binascii.hexlify(adv.mac)))
                    print("Geraete Sendestaerke = {}".format(adv.rssi)) 
                    data_stream= str(adv.data)
                    self.data.setRssi(binascii.hexlify(adv.mac), adv.rssi)
                    self.data.setDaten(binascii.hexlify(adv.mac), data_stream.replace("\\", ";"))
                    break
    except:
        pass

We use to look for a certain MAC. Sometimes we get plenty of Results, sometimes we dont....and when we dont, we usually will never get any Data from that WiPy and it will need several restarts before it finds anything again.

[livius]

@daniel said in Features wish list:

Encryption of Python scripts to protect code.

Do you have any info about above feature?

[gregcope]

@daniel @seb Another firmware idea;

As Pycom boards are promoting low power, can we reduce radio power; would it be an idea to either;

• Disable all radios at boot (like you can with wifi; pycom.wifi_on_boot(False))
• By default they are all off anyway

[rcolistete]

Voting for "@micropython.native/viper/.asm_xtensa" decorators on PyCom MicroPython, so we can optimize the speed of important code.