New firmware release 1.6.12.b1

[Innocenzo]

Very Nice for BLE !

I think that also bugs related to SSL Socket Server Side (https://forum.pycom.io/topic/995/ssl-socket-server-side-on-wipy-2-0) must be considered in the next firmware release.

Good Works an Thanks.

[robert-hh]

@daniel Hello Daniel, pin interrupt response times did not really improve. I had still rare cases of about 1 ms resposne time, with most responses within 150 µs, and 50 µs fastest response. Multiple triggers on slow pulses got fewer. I assume these cannot be avoided by firmware.
B.T.W.: When do you plan to update the github repository? I have the habit of putting some code into frozen bytecode.

[robert-hh]

@daniel This version does not run .mpy files from the files system any more. It looks like you have the wrong setting in mpconfigport.py, or the line:
#define MICROPY_PERSISTENT_CODE_LOAD (1)
is missing.

[Shaun]

This update seems to be a good one, thanks Daniel.
I no longer am running out of memory and so far have not experienced any mysterious application hanging. The sporadic and temporary halting/hiccupping of my application has also vanished. I suspect I must have been bumping my head against the "memory fragmentation issue caused by the timer alarms" and "General fixes and improvements to time.sleep(), time.sleep_ms() and time.sleep_us()"

[this.wiederkehr]

Where can I find the sources in order to rebuild myself? Where is the development actually happening?
Last commit to https://github.com/pycom/pycom-micropython was on 7th of march..

Thanks for clarifying.

Regards This

[jmarcelino]

@this.wiederkehr
That's the old source tree, you should use https://github.com/pycom/pycom-micropython-sigfox now but it hasn't got the very latest updates yet

[this.wiederkehr]

@jmarcelino: Thanks for your answer although that repo isn't very up to date either ( last commit 24 days ago).

[brotherdust]

@jmarcelino, can you confirm where development is actually happening these days? The source repos are out of date. Pycom used to be really good at keeping the sources in-sync with the current firmware release, but it seems to be a low priority now. I do remember an announcement that the sources will be merged with the official micropython tree, but I'm not seeing any commits or pull requests that would show this is actually happening. Any thoughts?

Thanks!

[jmarcelino]

@brotherdust
As far as I know (and I'm not Pycom employee) development is still ongoing on at https://github.com/pycom/pycom-micropython-sigfox but yes sources aren't in sync with the latest version, just slightly ahead of 1.6.9.b1

This has happened a few times in the past, sometimes they're really good at it sometimes it takes a bit longer. Not to be a stalker or anything :-) but I saw Pycom recently tweet about hackaton in Shanghai and Daniel was there so that may be the reason.

They have started some integration with the official MicroPython and there's been a few pull request, Daniel explained in another thread https://forum.pycom.io/topic/550/pycom-and-damien-george-join-forces-for-the-esp32/20

[Innocenzo]

Something strange happens with my code that worked well with previous firmware!

import usocket as socket
from network import WLAN


def connectWeb(server_websocket):
    webaddr = socket.getaddrinfo("0.0.0.0", 80)[0][-1]
    print("Bind address info:", webaddr)

    server_websocket.bind(webaddr)
    server_websocket.listen(5)
    print("Listening, connect your browser to http://<this_host>:80/")

    while True:
        res = server_websocket.accept()
        client_sock = res[0]
        client_addr = res[1]
        print("Client address:", client_addr)
        print("Client socket:", client_sock)
        print("Request:")
        req = str(client_sock.readline())
        print(req)
        while True:
            h = client_sock.readline()
            if h == b"" or h == b"\r\n":
                break
            print(h)
        ib = req.find(':')
        if ib > 0:
            str = req.split(":")
            ssid = str[1]
            pwd = str[2]
            security = ["None","WEP","WPA","WPA2"]
            sec = security[int(str[3])]
            wlan.init(mode=WLAN.STA)
            wlan.connect(ssid,  auth=(sec,  pwd),  timeout=5000
            utime.sleep_ms(5000)
            if not wlan.isconnected()
                f = open('connect.txt','w')
                f.write("0")
                f.close()
                machine.reset()
            else:
                f = open('connect.txt', 'w')
                f.write("1")
                f.close()
                f = open('ssid.txt', 'w')
                f.write(ssid)
                f.close()
                f = open('pass.txt', 'w')
                f.write(pwd)
                f.close()
                f = open('sec.txt', 'w')
                f.write(sec)
                f.close()
                break
        else:
            with open('index.html', 'r') as html:
                client_sock.send(html.read())

        client_sock.close()

print("INIT")
wlan = WLAN()
wlan.init(mode=WLAN.AP, ssid = 'WiPy', auth=(WLAN.WPA2,'testwipy2'), channel=7, antenna=WLAN.INT_ANT)
wlan.ifconfig(1, config=('192.168.4.1', '255.255.255.0', '192.168.4.1', '0.0.0.0'))
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
connectWeb(s)

return

Client address: ('192.168.4.2', 40725)
Client socket: <socket>
Request:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "test.py", line 80, in <module>
  File "test.py", line 23, in connectWeb
NameError: local variable referenced before assignment

[robert-hh]

@Innocenzo What I see is that you use "str" both as built-in function and as local variable. That will cause confusion. Although it should not give the error message you show.

[robert-hh]

@daniel Thanks for uploading the recent code to the repository.

[Innocenzo]

@robert-hh Thank you . Now it seems to work. I do a stupid mistake :( . Who knows why it worked with the old firmware version? :D

[yahia]

I have noticed since the previous firmware that ftp and telnet performance has dipped for the lopy. It is very slow especially while using the telnet REPL prompt. UART REPL prompt shows no issues at all though. Does anyone face a similar issue?