New Firmware Release Candidate v1.20.0
-
Hello Everyone ,
we've uploaded new Firmware Release
v1.20.0.rc0
as a candidate release for coming new stable releasev1.20.0
this release include the following changes:Improvements:
- Organized ports under one directory
- Micropython v1.9.4
- Disable/enable GIL when transmitting/receiving pulses in RMT module
- Unlock the GIL while accessing queues
- Add script to build release package via makefile or script in tools
- Improving Non-Blocking sockets
- Adaption for uasyncio MicroPython library
- Exposing new Socket Options
- Major LTE module Updates
- Re-structring of Frozen folder
- Fixed Issue with memory leak in thread lock creation
- Fixed problem in antenna switch in newer esp32 chip models
- General fixes and improvements to the LoRaWAN stack
- Applied workaround for
socket.connect
timeout - Added timeout option for
ussl.wrap_socket
to timeout SSL Handshake - Enabled reading the value of any descriptor with standard defined 2byte UUID in BLE
- Added Bluetooth timeout parameter to bluetooth.connect()
- Added support for new LTE bands (5,8)
New Features:
- Introduced new Filesystem
LittleFS
- Enabled uzlib in Micropython
- Added LightSleep functionality
- Added Dynamic filesystem functionality and new Bootmgr function in Pycom module
- Added support for RTC memory operations Read/Write
- Added Lora Mesh - openthread protocol
- Build Process now support building Pybytes firmwares via Build option
VARIANT
- New Frozen Libs for LTE Sequans modem upgrades
WiFi Updates:
- Added new API to get list of STAs connected to Soft-AP
- Updated wlan_scan to include other parameters
- Added timout handling in wlan_connect + refactoring
- Added new API for setting max tx power for Wifi
- Added Set/Get API for Country configuration
- Refactored "wlan_setup" function
- Fixed Issue of ftp/telnet servers enabling when wifi_on_boot is not enabled
- Added new API wlan.joined_ap_info()
- Added API to get/set wifi protocol + updated wlan_channel to support sniffing
- Added support for setting mac addr for STA and AP
- Added API for sending Raw 80211 messages
- Added promiscuous mode
You can download the sources from https://github.com/pycom/pycom-micropython-sigfox/tree/v1.20.0.rc0
You also can flash Pycom boards with this release by choosing
development
type in Firmware updater toolA link to Documentation page will be added soon.
Note: The function
os.mkfs()
has been replaced withos.fsformat()
To format the internal file system, useos.fsformat('/flash')
andos.fsformat('/sd')
to format SD cards (card needs to be mounted as '/sd')To mount the SD card, use this code:
sd = SD() fs = os.mkfat(sd) os.mount(fs, '/sd')
-
Was in the watch out for the below upgrades lately. Glad
Added support for setting mac addr for STA and AP
Added API for sending Raw 80211 messages
-
This post is deleted!
-
@robert-hh said in New Firmware Release Candidate v1.20.0:
This is all a little bit tedious, so I avoid to do it.
I remember we had a discussion about this on GitHub around Christmas last year...
Ideally the Makefile should know which branch of pycom-esp-idf should be used and clone / checkout / submodule update as necessary. It could also run
make -C ../mpy-cross all
before building the firmware as it should only rebuild if necessary. However checking all this before every build would probably be very annoying if it increases the build time significantly especially if you just made a small change between builds. Maybe adding this asmake prepare
would be better... plus a small post git checkout script that creates a file .force_prepare that would tell make to run the prepare step first so you don't forget.Of course you can always keep two separate firmware directories, one for the master / stable and one for the release-candidate branch. You can also have a shallow clone of the IDF in each directory (
git clone --depth=1 --recursive -b [master | idf_v3.1] https://github.com/pycom/pycom-esp-idf.git esp-idf
) and then use a relative IDF_PATH (export IDF_PATH=../esp-idf
).We also plan to change the way we use branches in this repository. Rather than master being the latest stable release, we will create a branch for each major release version. If we did this today, we would have branches called release/v1.18 for stable and release/v1.20 for the release candidate. The master branch would always have the latest code so we can publish hot fixes without creating a full new release for the software server and firmware updater.
-
@snock uart.read() without argument does the same as uart.readall(). But it would have been better to keep readall() as an alias, especially since it is still documented.
-
It looks like UART.readall() is missing therefore uModbus does not work.
>>> print(dir(UART)) ['__class__', '__name__', 'EVEN', 'ODD', 'any', 'deinit', 'init', 'read', 'readinto', 'readline', 'sendbreak', 'wait_tx_done', 'write'] >>> print(os.uname()) (sysname='GPy', nodename='GPy', release='1.20.0.rc7', version='v1.9.4-2833cf5 on 2019-02-08', machine='GPy with ESP32')
-
@robert-hh, @Xykon : Thanks for the tips! Changing from idf v3.1.1 to 3.1 did the trick!
-
@xykon When switching between master and release-candidate branch, one not only has to change the branches in esp-idf (and not forget to do the submodule update), but also mpy-cross has to be rebuilt.
What I do:- start with cleaning both the esp32 target and the mpy-cross target,
- then switch branches & update submodules,
- build mpy-cross
- build the ESP32 binary
This is all a little bit tedious, so I avoid to do it.
-
@brotherdust The official IDF version for release-candidate branch is
idf_v3.1
(see Jenkinsfile)Also make sure to update submodules in both the IDF and the firmware repo (see README.md)
-
Any thoughts here?
Do you use an old esp-idf branch? The pycom-esp-idf master is an old version used by the stable firmware. If you want to compile 1.20 you have to switch to v3.1.something. I am on the 3.1.1 branch.
-
@iwahdan
Getting build errors on release-candidate:HEAD (2/27/19):LINK build/WIPY/release/application.elf lib/libbt.a(bt.o):(.literal.btdm_check_and_init_bb+0x4): undefined reference to `btdm_rf_bb_init_phase2' lib/libbt.a(bt.o): In function `btdm_check_and_init_bb': /Users/iwahdan/esp/pycom-esp-idf/components/bt/bt.c:1165: undefined reference to `btdm_rf_bb_init_phase2' collect2: error: ld returned 1 exit status make: *** [application.mk:632: build/WIPY/release/application.elf] Error 1
Any thoughts here?
Thanks!
-
This post is deleted!
-
@iwahdan
May I suggest enabling OrderedDict in collections?#define MICROPY_PY_COLLECTIONS_ORDEREDDICT (1)
-
@iwahdan @Xykon
What happend to the development branch and version 1.19 (which is still in beta)?
Was it abandoned? As far as I can see they both branched from 1.18, but with similar changes, especially regarding the new directory structure.
Is everything that was new/fixed in 1.19 also in 1.20?
-
@crumble You have to do that after any checkout in the esp-idf repository. So if you change to v3.1, you have to repeat that. And in the Micropython subdirectory you have to rebuild mpy-cross.
-
@robert-hh
Thanks a lot Robert. I had done this in master branch only or it failed for some reason.Was not able to link it with idf_v3.1 but idf_v3.1.1 works.
-
@crumble Dis you issue in the esp-idf folder the command:
git submodule update --init
-
Update IDF libraries to pycom-esp-idf/idf_v3.1 ebff2ed
I tried to compile debian submodule on win10. But fail with a lot of the idf_v3.1* branches.
It misses include files from the folder mbedtlsmods/modussl.h:19:25: fatal error: mbedtls/net.h: No such file or directory compilation terminated. mods/moduhashlib.c:26:26: fatal error: mbedtls/sha1.h: No such file or directory compilation terminated. In file included from mods/modussl.c:28:0: mods/modussl.h:19:25: fatal error: mbedtls/net.h: No such file or directory compilation terminated. In file included from mods/lwipsocket.c:31:0: mods/modussl.h:19:25: fatal error: mbedtls/net.h: No such file or directory compilation terminated.
origin/master compiles without problems.
Can I give the original idf v3.1.2 a try or do I need your changes?
Hey, there is a change for i2c. I have no clue what this means, but i had to have it. Just too scared to brick the device without your go ;)
-
Bad luck today run into the i2c issue on init of pytrack:
File "main.py", line 62, in <module> File "lib\pytrack.py", line 8, in __init__ File "lib\pycoproc.py", line 102, in __init__ File "lib\pycoproc.py", line 164, in set_bits_in_memory File "lib\pycoproc.py", line 155, in magic_write_read File "lib\pycoproc.py", line 117, in _read OSError: I2C bus error
It will be nice, if this message has more details inside the development firmware. It is the same when reading or writing on the python level. But maybe a "doesn't work on my machine" is helpful, too ;)
-
I'm testing this new fw v1.20.0.rc4 release with GPY with lasted NB modem fw.
Resume:
1 - I'm able to connect and send data over NB (Portugal - MEO operator)
2 - rtc.ntp_sync() is working over NB and WIFI
3 - rtc.synced() is working over NB and WIFI
4 - I notice that sometimes the usocket.read() don't timeout, I will continue doing more tests.keep the good work.