New firmware release v1.11.0.b1 and new updater tool version v1.1.4.b1 (FiPy and GPy support)
-
This release adds support for the FiPy and GPy and it also requires the usage of the new updater tool. Make sure to get it here:
Updater tool v1.1.4.b1 release notes:
- Add support for the FiPy and the GPy.
- Add support for using Pysense/Pytrack to deploy the firmware update. With these boards the update is performed without requiring cable jumpers or pressing the reset button.
Firmware 1.11.0.b1 release notes:
-
Add the LTE class as part of the network module. Available for the FiPy and the GPy.
-
Add
tx_done()method to the UART class. -
Correct timer task priority. Fix downlink issue with LoRaWAN introduced in the previous release.
-
Add
pycom.ota_verify()method to check the integrity of the update binary. -
Add
machine.temperature()method:Read ESP32 internal temperature sensor (not an official API, unreliable - see
https://github.com/espressif/esp-idf/issues/146) -
Make sure to call nvs_commit after nvs_erase_all.
-
Allow adding channels with LoRaWAN data rates lower than DR5 - fixes issue #96
-
Breaking change: the default MISO pin for SPI has been moved from P12 to P14. Remember that SPI, UART, I2C pins can be assigned pretty much anywhere.
With this release the FiPy support WiFi, Bluetooth, LoRa and LTE (Cat-M1). Sigfox support will be added later this week.
Cheers,
Daniel
-
@Smeedy it will be available in a new release today or tomorrow.
-
@daniel any news on Sigfox for the 1.11 on FiPy?
-
@xykon Running Win7 Pro SP1 64 bit. The installer seemed to run OK but I definitely didn't get an icon. Uninstalled and reinstalled multiple times (even tried "Run as Administrator") This machine rarely gets rebooted but it did get a reboot since my original e-mail. Today when I reinstalled the firmware tool now get a start menu icon(!) Go figure ...
-
@tcottle We have tested the firmware update tool on Windows 7 multiple times and never encountered any issues.
Could you please provide the type (32/64bit) of your Windows 7 installation.
Did the installer create the Icon for the firmware update tool in the start menu?
Did you get any error message when trying to launch the tool from the start menu?
I'm working on a new firmware update tool that will work with a single executable file but until this is ready I would like to make sure the current version doesn't have any issues.
Thanks a lot for your assistance.
-
I used this on Win7 (64) with no issues.
Installer put a link to the executable in my start menu.
-
@tcottle thanks for this bug report. We well do some more testing as in principle it works fine on our Win7 test machines.
-
@daniel I never got an executable. The installer created and populated python 2.7 and installer directories and then quit. After several install and uninstall cycles I tried it on Win10 machine and everything worked fine
-
@tcottle it should work on Win7 as well. What errors do you get?
-
@daniel Updater tool does not work on Win7(!) No indication of Win10 requirement in the docs and the installer does not catch this error.
-
@seb said in New firmware release v1.11.0.b1 and new updater tool version v1.1.4.b1 (FiPy and GPy support):
You would only need to change the way you instantiate the SPI class to use the old pin layout, you can find an example of this here: https://docs.pycom.io/chapter/firmwareapi/pycom/machine/SPI.html
No need to recompile the whole firmware. The reason this has been changed is because on new devices P12 controls the external WiFi antenna switch and therefor should not be used for SPI. The pinout diagrams will soon be updated to reflect these changes.Ah, thank you for clarification, that helps :)
@livius said:
It is good practice that if you have default configuration which can by changed by params,
to specify default params also.Yep, I agree :) I was under the impression that this mapping is something that is done in the ESP32 firmware, not in the "MicroPython userspace", which would have been a bit more complicated in my case.
-
@seb Thanks, and in case we do not talk again: Merry Christmas
-
@robert-hh said in New firmware release v1.11.0.b1 and new updater tool version v1.1.4.b1 (FiPy and GPy support):
@daniel said in New firmware release v1.11.0.b1 and new updater tool version v1.1.4.b1 (FiPy and GPy support):
P12 is also
the safeboot pin andthe antenna select pin in the WiPy3, LoPy4, GPy and FiPyIf you look into the Pin-out diagrams, there is still a mess about that topic.
Hi,
I just looked over all of the pinouts, only the LoPy4 remained to fixed and has now been resolved. The pinouts now all accurately reflect where each module has its antenna select. I will soon be improving the documentation around the other issue you raised with safe boot.
-
@daniel said in New firmware release v1.11.0.b1 and new updater tool version v1.1.4.b1 (FiPy and GPy support):
P12 is also
the safeboot pin andthe antenna select pin in the WiPy3, LoPy4, GPy and FiPyIf you look into the Pin-out diagrams, there is still a mess about that topic.
-
Hi, thanks for the feedback, the documentation will be undergoing a lot of improvements soon and we will definitely keep this in mind.
-
There’s no need to recompile firmware. Every peripheral (except for the SD card) allows to assign its pins anywhere (by passing the pins argument to the constructor). However, if no pins argument is given, a set of default pins is used. P12 is also the safeboot pin and the antenna select pin in the WiPy3, LoPy4, GPy and FiPy.
Just use the pins argument in the constructor and specify P12 for MISO and that’s it.
I hope that this is clear.
Cheers,
Daniel
-
@dbrgn
It is good practice that if you have default configuration which can by changed by params,
to specify default params also. It is helpfull for self documenting (you do not need to look into docs what is default or place some comments) and then such changes do not affect you at all.
But this is only my little POV.
-
You would only need to change the way you instantiate the SPI class to use the old pin layout, you can find an example of this here: https://docs.pycom.io/chapter/firmwareapi/pycom/machine/SPI.html
No need to recompile the whole firmware. The reason this has been changed is because on new devices P12 controls the external WiFi antenna switch and therefor should not be used for SPI. The pinout diagrams will soon be updated to reflect these changes.
-
@daniel said in New firmware release v1.11.0.b1 and new updater tool version v1.1.4.b1 (FiPy and GPy support):
Breaking change: the default MISO pin for SPI has been moved from P12 to P14. Remember that SPI, UART, I2C pins can be assigned pretty much anywhere.
That's a pretty small mention for a breaking change. Also, I could not find this change reflected in the pinout docs (https://docs.pycom.io/chapter/datasheets/development/lopy.html). A lot of people will also have a version of that pinout printed out or stored in a project directory, without any expectation of pinout changes.
If I had already made hardware that relies on the MISO pin to be on P12, would I have to compile my own patched version of the firmware for every release? Or is this configurable in
boot.py? Was there a technical reason for the change (indicating that it's better to have MISO on P14 than P12)?
-
@xykon I went line by line through my code. Visual Studio code was acting strange... I had to reinstall VS Code, manually uninstall the Pymakr extension and reinstall it... again.
I have been able to get my code working without freezing up. Thanks to @Xykon 's help, I narrowed it down to freezing up caused by my code, not the firmware. I had a line in my boot.py that was redundant, 'Upload' worked after I removed the machine.main('main.py')Thank you for your help
