New Firmware Development release v1.19.0.b4
-
Hello everyone,
Development firmware v1.19.0.b4 is now released. you can now download the firmware to pycom devices via the firmware updater or download the source from here.
Important: This firmware has support for both FatFS and LittleFS and will default to using FatFS unless you set the correct File System when flashing the board. For this reason, you can only flash this firmware using the new beta firmware updater 1.15.2.b0 or by downloading the firmware file manually and flashing it via the local file option.
For documentation you can find it here.
Release Notes:
Added Feautures:
-
Added RTC memory support
-
Added support for including uasyncio micropython module
-
Added Lora mesh functionality with openthread protocol
Fixes:
- Fixed problems with Non-Blocking Sockets
For new Lora Mesh functionality we added example scripts that you can find here
-
-
@reidfo said in New Firmware Development release v1.19.0.b4:
On both mac and linux I'm getting unexpected sha1 checksum when I try to install the latest development release on FiPy.
Are you using the beta firmware updater?
-
On both mac and linux I'm getting unexpected sha1 checksum when I try to install the latest development release on FiPy.
-
@martijnthe said in New Firmware Development release v1.19.0.b4:
what's the timeline for a non-beta release of v1.19.0?
We are hoping to publish the first release candidate next week.
-
@iwahdan or @Xykon what's the timeline for a non-beta release of v1.19.0?
Mostly interested in LittleFS (for robustness and wear-levelling) and the newer micropython.
-
Measured using only software : about 16 ms to wake up from light sleep. Both using wake on pin (interrupt) or timed light sleep.
Need to confirm with external measurement : i(t) powering LoPy4 by using oscilloscope + shunt resistor.
-
Any measure of time (in ms) to wake up from light sleep mode ?
I'd like to know if a wake on pin (external signal) from light sleep mode would be fast enough for some signal frequencies : 10 Hz ? 50 Hz ? 100 Hz ? 1000 Hz ?
-
@tuftec , Also you have to take into consideration the fact that if board resets or power is lost the Time is rested to unix epoch , you can use
RTC.ntp_sync()to Sync time using an NTP server in case of hard resets.
-
Sorry about the scant information.
I am building custom hardware around the LoPy4 and FiPy devices.
So, based on the post by @iwahdan , does this imply that the RTC should keep going in DeepSleep for both the LoPy4 and FiPy modules? This is contrary to information I was given some time ago.
If the RTC keeps going that would be a big advantage for my application.Peter.
-
Triple thanks @cmisztur!
-
Hi @tuftec, well as @jcaron mentioned if you are using a Pycom device with Deepsleep shield you cannot keep track of time using RTC as the device is completely powered Off, however if you are using the newer boards that don't require the Deepsleep shield you can keep track of time using the RTC module in Micropython, you would set the time once using
RTC.init()and the RTC would keep counting from that time even in deepsleep , you can check time after wakeup usingRTC.now()
-
OK - Thanks @iwahdan.
-
@tuftec you may want to let us know which hardware combination (module + board) and what deep sleep mode you are using.
If you are using one of the “older” boards (e.g LoPy, not LoPy 4) with a Pysense, Pytrack or the deep sleep shield, and the PIC-controlled deep sleep, then the ESP32 is indeed completely powered down during deep sleep.
If you are using one of the more recent boards (e.g LoPy) and
machine.deepsleep, I believe the RTC keeps running during deep sleep.
-
It is good to see that RTC memory support has been added.
Is there a mechanism that can keep the RTC operational when the device is in deep sleep?
I need a way to maintain system time but require to deepsleep regularly to save power (battery operated).
My original solution for this was to implement a s/w RTC and to save its state every time I go into deepsleep. I would then use my knowledge of the time in deepsleep (set by the deepsleep timer) and measuring execution time of the start up code (using the chrono functions) to then update my s/w RTC upon waking.
Very messy but it sort of works. Not very accurate though.
If there was a way to keep the RTC running (power still applied) then I could hopefully have a much better solution. Using other ESP32 based devices running standard Micropyrhon, it would appear that the RTC function actually continues to operate during deepsleep.
Have I missed something???? Is there a suggested way to use the RTC when using deepsleep?Peter.
-
@soulsurfer here, I documented the process https://medium.com/@chrismisztur/pycom-uasyncio-installation-94931fc71283
-
@iwahdan I think it would be nice to have this as frozen modules by default in the future.
-
@soulsurfer, using FTP or pymkr you can upload the uasyncio modules to your Pycom device with the following hierarchy :
- uasyncio sub-modules into
/flash/lib/uasyncio - websocket.server sub-module under:
/flash/lib/uasyncio/websocket - collections sub-modules into
/flash/lib/collections - logging sub-module into
/flash/lib
And then you can import
uasynciolibrary into your script and start using it
- uasyncio sub-modules into
-
@iwahdan - Given the recent change in wording (and the fact that I'm a micropython noob!) are there explicit instructions anywhere on precisely how to "includ[e] uasyncio micropython module[s]" plus the required libraries?
-
@cmisztur, We've done some updates in this Dev release to support including the uasyncio lib from micropython.
The uasyncio library is provided by MicroPython under micropython-lib: https://github.com/micropython/micropython-lib/tree/master/uasyncio
Unlike CPython's asyncio library it is splitted into several parts:The uasyncio library relies on the micropython-lib/collections (defaultdict, deque) and logging libraries.
Note: I've updated my Release post as it was wrongly implying that the uasyncio already included in firmware
-
@iwahdan Thanks. Should importing
uasynciowork in this release ?
