Firmware Release v1.20.1



  • @cmisztur Sorry, I never looked at pybytes.



  • Thank you.

    Regarding 'legacy' vs 'pybytes' variants. Does the PyBytes variant auto connect to PyBytes platform and maintain connection? What is the difference between 'legacy' and 'pybytes'?



  • Hello @iwahdan, promissing update! Thanks to all people involved.

    I will test new firmware flashing a module later today. I have two questions regarding this update:

    1. It's now ULP co-processor supported? We have a product with custom hardware + lopy4 and we want to add capability to count pulses on two digital inputs while sleeping (measuring water consumption, etc..)
    2. It's possible to change wifi mode to LR (Espressif's Long Range protocol) by code?

    If still not supported (1 or 2) I don't know if may open an issue on github in order to pycom keep track of improvements, or maybe is better to leave written here.

    Regards



  • @rskoniec Do you use the PyBytes variant? According to the code this variant always returns False (and it does not set this flag). See the code snippet from pycom_config.c:

    
    bool config_set_wifi_on_boot (uint8_t wifi_on_boot) {
        if (pycom_config_block.wifi_config.wifi_on_boot != wifi_on_boot) {
            pycom_config_block.wifi_config.wifi_on_boot = wifi_on_boot;
    #if (VARIANT != PYBYTES)
            return config_write();
    #endif
        }
        return true;
    }
    
    bool config_get_wifi_on_boot (void) {
    #if (VARIANT == PYBYTES)
        return false;
    #endif
        return pycom_config_block.wifi_config.wifi_on_boot;
    }
    
    


  • @rskoniec said in Firmware Release v1.20.1:

    pycom.wifi_on_boot(True)

    Does it change if you use:

    pycom.wifi_on_boot(True, True)

    The code allows a second parameter, which is not documented. But as I understand it, it forces the immediate startup of WiFi. It should not affect the stored state.



  • @iwahdan I'm not able to change pycom.wifi_on_boot

    >>> os.uname()
    (sysname='FiPy', nodename='FiPy', release='1.20.1', version='v1.11-12f4ce0 on 2019-10-06', machine='FiPy with ESP32', lorawan='1.0.2', sigfox='1.0.1', pybytes='1.1.2')
    >>> import pycom
    >>> pycom.wifi_on_boot()
    False
    >>> pycom.wifi_on_boot(True)
    >>> pycom.wifi_on_boot()
    False
    


  • @robert-hh said in Firmware Release v1.20.1:

    @iwahdan Hellol Islam. Thank you for the update. I have a few question and comments:

    1. Why was the update pushed to the branch called Release/v1.20.1 and not master. These many new branches confuse.

    we have restructured our GitHub public Repo to have a separate branches for 1.18 and 1.20 FWs (under Release) - Daily development will be done on a new default branch (Dev) (previously we used to do the main Dev privately and do weekly/monthly releases to public repo).
    This will make it easier for people to Contribute to Our Firmware plus better traceability of opened Issues.
    we recommend you open any pull request on that Branch (Dev).

    1. The bug in the LTE module I reported in Issue #338 still persists, but may not always pop up:
      In handling of the attach command inside modlte.c, the length of the command AT+SMDD (and others) is not set! Lines affected: 310, 654, 670. Compare to these place the use of the function lteppp_send_at_command in line 179, where the data length IS set. A test confirmed the bug: if I specify band=8, I get an error: band 8 not supported. If I omit band=8, attach works.

    Can you open a PR on Dev branch?

    1. There is still the glitch in handling the bits=xx argument in adc.init. Before, the only accepted argument & value for adc.init() was bits=12, and even that was discarded. With that change, the function meets the documentation and works as expected. See PR #327

    Just changed Base of your PR to Dev, can you please update?

    Edit: Setting dataLen in the calls to lteppp_send_at_command() makes attach wotk again with specifying the band.



  • @iwahdan Hellol Islam. Thank you for the update. I have a few question and comments:

    1. Why was the update pushed to the branch called Release/v1.20.1 and not master. These many new branches confuse.
    2. The bug in the LTE module I reported in Issue #338 still persists, but may not always pop up:
      In handling of the attach command inside modlte.c, the length of the command AT+SMDD (and others) is not set! Lines affected: 310, 654, 670. Compare to these place the use of the function lteppp_send_at_command in line 179, where the data length IS set. A test confirmed the bug: if I specify band=8, I get an error: band 8 not supported. If I omit band=8, attach works.
    3. There is still the glitch in handling the bits=xx argument in adc.init. Before, the only accepted argument & value for adc.init() was bits=12, and even that was discarded. With that change, the function meets the documentation and works as expected. See PR #327

    Edit: Setting dataLen in the calls to lteppp_send_at_command() makes attach wotk again with specifying the band.
    Edit2: Thank you for keeping the espressif reset mode option


Log in to reply
 

Pycom on Twitter