New Firmware Release Candidate v1.20.0

[crumble]

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 ;)

[crumble]

@xykon

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 mbedtls

mods/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 ;)

[robert-hh]

@crumble Dis you issue in the esp-idf folder the command:

git submodule update --init

[crumble]

@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.

[robert-hh]

@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.

[Sympatron]

@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?

[brotherdust]

@iwahdan
May I suggest enabling OrderedDict in collections?

#define MICROPY_PY_COLLECTIONS_ORDEREDDICT (1)

[brotherdust]

This post is deleted!

[brotherdust]

@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!

[crumble]

@brotherdust

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.

[Xykon]

@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)

[robert-hh]

@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]

@robert-hh, @Xykon : Thanks for the tips! Changing from idf v3.1.1 to 3.1 did the trick!

[snock]

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]

@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.

[Xykon]

@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 as make 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.

[iwahdan]

This post is deleted!

[JamieLanger]

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