New firmware release v1.7.7.b1 (REQUIRES NEW UPDATER TOOL)

daniel

Hello,

A new firmware release is out. The version is 1.7.7.b1. Here's the change log:

Before upgrading to this version make sure to get the latest updater tool firs. Read this port for more info: https://forum.pycom.io/topic/1535/important-new-firmware-update-tool-released-version-1-1-2-b1

esp32: Correct the OTAA (over the air update) functionality
esp32: Update to the latest IDF. Solve FreeRTOS context switch crash.
esp32: Update Sigfox module to work with the new Sigfox library v1.93
esp32: Update Sigfox library to the latest version (v1.93).
esp32: Fix support for BLE indications on the GATT Server.
esp32: Properly close GATT server and client connections.
esp32: Only install the RMT driver for measuring pulses once.

In order to get the new firmware it, please user the updater tool that can be downloaded from here: https://www.pycom.io/downloads/

Cheers,
Daniel

kutysam

@daniel said in New firmware release v1.7.7.b1 (REQUIRES NEW UPDATER TOOL):

esp32: Fix support for BLE indications on the GATT Server.

I believe this is only for the server.
I hope BLE indications for GATT Clients (GATTC) is fixed soon :)
Currently, its not implemented.

robert-hh

@daniel It seems, as if with this release the issue of unstable file writes is gone. I ran the loop&write test six times up to 2 million passes = 2048000000 Bytes successfully, at which time it stopped intentionally to avoid writing more than 2 GB into a file. The maximum size that can be written is 4 GB, but beyond 2 GB the file size is displayed wrong (int vs. uint mismatch).

daniel

@robert-hh yes thanks. The issues was caused by a very obscure bug inside FreeRTOS:

esp32: Update to the latest IDF. Solve FreeRTOS context switch crash.

That bug was timing related, that's why it was so erratic.

BTW, It's not mentioned in the release notes, but the SD card frequency has also been increased back to 20MHz.

Cheers,
Daniel

robert-hh

@daniel said in New firmware release v1.7.7.b1 (REQUIRES NEW UPDATER TOOL):

BTW, It's not mentioned in the release notes, but the SD card frequency has also been increased back to 20MHz.

Yes, I noticed that, but forgot too mentioning it.

robert-hh

@robert-hh Besides the error code, OTA works. But there is something to be aware of, if OTA and wired flash is mixed. The firmware keeps two areas in flash, where the image can be stored using OTA, which are used alternatively (addresses 0x10000 and 0x1a0000). To determine which, a flash is kept. Flashing "make flash" and probably the updater always uses address 0x1000 without changing that flag. So if the active firmware is at 0x1a0000 after an OTA, and then "make flash" is then used to store a new image an 0x10000, this will not get active, since the startup code still assumes the active image at 0x1a0000. That state can reliably be reset by erasing the flash. Of course, one could also use another OTA load.

BetterAuto

Dost mine eyes deceive me? OTAA?? Can't wait to see that working!

Thanks Pycom team for all that you do.

Eric24

@daniel said in New firmware release v1.7.7.b1 (REQUIRES NEW UPDATER TOOL):

RMT driver for measuring pulses

What exactly is the "RMT driver for measuring pulses"? We are looking at various pulse counting options, so I'm interested in learning more about this.

jmarcelino

@Eric24
There is a pycom.pulses_get(pin,timeout) function but seems a bit primitive and "raw" at the moment - as far as I can see only used internally to calibrate the deep sleep timer.

You do get a list of (signal_level, duration) tuples, where duration seems to be in microseconds (RMT channel clocks = APB_CLK (80Mhz) / clk_div (80) but I'm not completely sure)

There's a set of fixed thresholds at the moment so it may be only useful for some applications.

daniel

@jmarcelino yes, it's microseconds.

@Eric24 we do have plans to make the function more generic. Your input regarding your needs to measure pulses would definitely help. What kind of API do you think will be more helpful for you?

Jurassic Pork

@daniel
hello,
in my DHT pure python library here to read a DHT sensor (temperature and humidity) i read the pulses send by the sensor like this :

    def __collect_input(self):
        # collect the data while unchanged found
        unchanged_count = 0
        # this is used to determine where is the end of the data
        max_unchanged_count = 100
        last = -1
        data = []
        m = bytearray(800)        # needs long sample size to grab all the bits from the DHT
        irqf = disable_irq()
        self.__pin(1)
        for i in range(len(m)):
            m[i] = self.__pin()      ## sample input and store value
        enable_irq(irqf)
        for i in range(len(m)):
            current = m[i]
            data.append(current)
            if last != current:
                unchanged_count = 0
                last = current
            else:
                unchanged_count += 1
                if unchanged_count > max_unchanged_count:
                    break
        #print(data)
        return data

not very accurate because samples are over 10 us
i have made a first try with the new function pulses_get like that :

    def read2(self):
        self.__send_and_sleep(0, 0.019)
        irqf = disable_irq()
        self.__pin(1)
        # collect data 
        data = pycom.pulses_get(self.__pin,500)
        enable_irq(irqf)
        return data

here is what i get :

it seems to be more accurate that the first method ! (real time in us of the pulses)
timing of the DHT :
DHT Timing

The first value for 1 level (88) seems to be the Start HI . We have the 40 data bits of the DHT !
to be continued ....

Eric24

@daniel Actually, my needs are for counting pulses, not measuring their duration (although that would certainly be useful, I don't have a specific use-case for it right now). My thinking on the pulse counting is that I'll have to wait until the ESP32's ULP is supported for it to be practical to do (i.e. pulse counting using interrupts or other methods require the module to be awake too much--at least once per pulse--whereas the ULP has the potential of being able to count pulses during deep-sleep).

robert-hh

@jmarcelino It looks as if this function is useful for the DHT sensors. There are solutions using pure python, but they sometimes fail.

this.wiederkehr

@daniel, @robert-hh I can confirm as well, that the sd-card error is gone with this release. Thanks!

Jurassic Pork

hello,
it seems that there is a problem with the function pulses_get

with this code :

       # pull down to low until 19 ms       
        self.__send_and_sleep(0, 0.019)
        data = pycom.pulses_get(self.__pin,100)
        self.__pin(1)
        print(data)
       time.sleep(5)

i acquire data from a DHT sensor.
the first time i run this code it is OK , i have all the pulses data in the data variable.
But if i run this code in a loop the second time , i have no data acquired.
Maybe i am wrong somewhere but if someone can check this.

Jurassic Pork

hello
@Jurassic-Pork (answer to myself :-) )
i think that i have found where is the problem. To work with the DHT , i need to put the used pin in mode OPEN_DRAIN (input / output) . I initialize my classe like this :

th = DTH(Pin('P3', mode=Pin.OPEN_DRAIN),0)

it seems that the function pulses_get change the mode of the pin used to INPUT. So the second time i try a read , it doesn't work.
with this change in my code :

        self.__send_and_sleep(0, 0.019)
        data = pycom.pulses_get(self.__pin,100)
        self.__pin.init(Pin.OPEN_DRAIN)
        self.__pin(1)

it is now ok in my loop :-)

Paco88

Is the git repository updated?

jmarcelino

@Paco88
Yes it is

Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

New firmware release v1.7.7.b1 (REQUIRES NEW UPDATER TOOL)

Pycom on Twitter