UIFlow 2.0.0 firmware preview version

Philip

Is Uiflow site down?

wkibler

Same here, flow.m5stack.com is not fully loading. It loads from a cached version in another browser but then will not upload to any device. I've tried Core2 and a Grey with new and old firmware.

When I move the code to the desktop version only half of it loads. many of my functions are missing. I am 2 hours before a public showing and I need this up and running please help.

felmue

@m5stack said in UIFlow 2.0.0 firmware preview version:

One firmware can be used on all M5STACK devices

Hello @m5stack

Trying the beta firmware on an M5Stamp C3 fails - I guess due to the risk architecture which probably requires a different bootloader. Or am I missing something?

When I flash to 0x1000 I get "Invalid image block, can't boot."
When I flash to 0x0000 I get "Invalid chip id. Expected 5 read 0. Bootloader for wrong chip?"

Thanks
Felix

felmue

Hello guys

using Thonny and M5AtomLite running UiFlow 2.0.0 beta firmware

MicroPython b084d9e-dirty on 2022-01-28; M5STACK with ESP32

I tried to scan for WiFi networks with this code:

import network
nic = network.WLAN(network.STA_IF)
nic.active(True)
res = nic.scan()
print(res)

but I get an error:

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
RuntimeError: Wifi Unknown Error 0x0101

Edit: when I install native ESP32 MicroPython firmware 1.17, e.g.

MicroPython v1.17 on 2021-09-02; ESP32 module with ESP32

the above code works to scan WiFi networks. What am I missing?

Thanks
Felix

IAMLIUBO

@genvex

Hi, sorry for taking so long to reply, just finished the Chinese New Year holiday :)

ulab will support, but lvgl for micropython will take a lot of flash space, we may only support some devices (such as CORE2, TOUGH, etc.), because the early basic flash chip is only 4M in size.

This needs to be discussed, maybe we will launch a service to generate firmware online, you can choose which functions or drivers are packaged into the firmware.

Have a nice day.
IAMLIUBO

IAMLIUBO

@aivarannamaa

Hi, sorry for taking so long to reply, just finished the Chinese New Year holiday :)

This is great news! The old MicroPython in M5Stack firmware was the last remaining obstacle holding me from removing some ugly workarounds in Thonny's MicroPython backend.
According to my quick initial test Thonny is happy with the new firmware. I tried the original gray M5Stack and Atom Lite. With the gray M5Stack even the "paste" communication mode, which for some reason did't work with M5 earlier firmwares, now seems to work without problems. With Atom Lite it still causes problems, which I'll investigate later.

Thanks, the old MicroPython firmware for M5Stack(or UIFlow firmware) there are indeed some incompatibilities with micropython (such as paste code in repl mode).

I also like the decision to use common firmware for all M5 devices and the fact that now one can use the same esptool arguments as for other ESP32 devices. This means Thonny users can use the built-in flashing dialog for M5 devices.

Yes, one firmware that works for all M5 devices would be a good choice, but this would also be a limitation since the flash chip size is different for different devices, but we can guarantee that the esptool arguments will be the same (only For ESP32, if it is S2 or C3, may need to add some additional parameters).

I'm considering adding a separate "MicroPython (M5Stack)" back-end in the upcoming Thonny 4.0, but this is warranted if it came together with M5-specific MicroPython stub files (.pyi) for autocompletion and static analysis (one of the main theme of Thonny 4.0 will be improved autocompletion).
This is where you could help me. Most likely I don't find time for compiling the stubs from the scarce documentation myself, but if you created the pyi-files describing M5-specific modules, I would include them in Thonny 4.0 under "MicroPython (M5Stack)" back-end.

Wow, this is really good news.Thank you very much, this is currently a very early preview firmware, and some API modifications and adjustments may be made later, but I am very willing to keep in touch with you, I will try to process a pyi file, is mypy tool okay?

Have a nice day.
IAMLIUBO

IAMLIUBO

@ajb2k3

Hi, sorry for taking so long to reply, just finished the Chinese New Year holiday :)

does this include the stamp pico and stamp C3?

I have not tested the STAMP series, but STAMP-C3 is not supported (the architecture is different and needs to be compiled separately)

Have a nice day.
IAMLIUBO

IAMLIUBO

@dario

Hi, sorry for taking so long to reply and thanks for report this bug, We will investigate this issue as soon as possible.

Have a nice day.
IAMLIUBO

IAMLIUBO

Hi @lmartu68 @wkibler @Philip,

Hi, sorry for taking so long to reply, just finished the Chinese New Year holiday :)

We did have some issues with our servers during the holidays, sorry about that, it should be fixed now, sorry again.

Have a nice day.
IAMLIUBO

IAMLIUBO

@felmue

Hi, sorry for taking so long to reply.

Trying the beta firmware on an M5Stamp C3 fails - I guess due to the risk architecture which probably requires a different bootloader. Or am I missing something?

I'm very sorry, it's my problem, I didn't say that this firmware does not support C3 chip, it currently supports ESP32, because of the different architecture, it is impossible to make a firmware support esp32, esp32-c3, esp32-s2, esp32-s3 at the same time.

ajb2k3

@IAMLIUBO I have been recommending a firmware builder for a while because of the issue you had with firmware size.

Please, please, please me need a stand alone server that can be run on a raspberry pi!

IAMLIUBO

@felmue said in UIFlow 2.0.0 firmware preview version:

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
RuntimeError: Wifi Unknown Error 0x0101

I tried it, there is indeed a bug, devices with psram might work, try it and we'll fix it.

P.S.

log:

>>> wifi = network.WLAN(network.STA_IF)
I (28862) wifi:wifi driver task: 3ffd3600, prio:23, stack:6656, core=0
I (28862) system_api: Base MAC address is not set
I (28862) system_api: read default base MAC address from EFUSE
I (28872) wifi:wifi firmware version: 0d44bbe
I (28872) wifi:wifi certification version: v7.0
I (28872) wifi:config NVS flash: enabled
I (28872) wifi:config nano formating: disabled
I (28882) wifi:Init data frame dynamic rx buffer num: 32
I (28882) wifi:Init management frame dynamic rx buffer num: 32
I (28892) wifi:Init management short buffer num: 32
I (28892) wifi:Init dynamic tx buffer num: 32
I (28902) wifi:Init tx cache buffer num: 32
I (28902) wifi:Init static rx buffer size: 1600
W (28912) wifi:malloc buffer fail
I (28912) wifi:Init static rx buffer num: 3
I (28912) wifi:Init dynamic rx buffer num: 32
E (28922) wifi:Expected to init 10 rx buffer, actual is 3
I (28922) wifi:Deinit lldesc rx mblock:0
I (28932) wifi:Deinit lldesc rx mblock:0
I (28932) wifi:Deinit lldesc rx mblock:0
I (28932) wifi:Deinit lldesc rx mblock:0
I (28952) wifi_init: rx ba win: 6
I (28952) wifi_init: tcpip mbox: 32
I (28952) wifi_init: udp mbox: 6
I (28952) wifi_init: tcp mbox: 6
I (28952) wifi_init: tcp tx win: 5744
I (28962) wifi_init: tcp rx win: 5744
I (28962) wifi_init: tcp mss: 1440
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: Wifi Unknown Error 0x0101

Thanks for report this :)

Have a nice day.
IAMLIUBO

IAMLIUBO

@ajb2k3

@IAMLIUBO I have been recommending a firmware builder for a while because of the issue you had with firmware size.
Please, please, please me need a stand alone server that can be run on a raspberry pi!

This is a little lower priority, there are still some important things to deal with, we will release a preview version as soon as possible (online firmware function selection and generation).

Thanks for your recommend and help us be better.

Have a nice day.
IAMLIUBO

ajb2k3

@iamliubo BTW I’m not stating here just moaning, I am actually working on documentation for UIFlow it’s just that the IoT side of things is proving a challange. I’m not sure if the issue with Blynk is Blynk side or UIFLOW side.

felmue

Hello @IAMLIUBO

no need to apologize - I hope you had a great holiday.

Re ESP32c3: thank you for the clarification. I suspected that much. The different architecture requires a different firmware.

Re WiFi: I can confirm that scanning for WiFi APs works on an M5Core2 (which has PSRAM). So indeed, it seems to be a RAM issue.

Thanks
Felix

IAMLIUBO

@ajb2k3

Thanks for your contribution.

I’m not sure if the issue with Blynk is Blynk side or UIFLOW side.

Based on previous discussions here, there are indeed some issues that need to be identified and dealt with, which we will test and investigate as soon as possible.

IAMLIUBO

@felmue

Re WiFi: I can confirm that scanning for WiFi APs works on an M5Core2 (which has PSRAM). So indeed, it seems to be a RAM issue.

Yes, thanks for you feedback, I always use CORE2 for develop and test,so I didn't notice that, we will release some new FW at this friday with more bug fixed.

MTal

Hello, please when you launch UiFlow 2.0 check all the existing functions, most of them doesn't work

i.e. I am trying to use UHF-RFID unit on UIFlow and most of blocks don't do anything or give errors:

Set region code ERROR name REGIN_EU isn't defined
Multiple polling read NOT WORKING
Select mode NOT WORKING
Set tx power ALWAYS RETURN 256
Enable /disable continuous carrier NOT WORKING

And so on...

judezzz

Hi @IAMLIUBO
Will LVGL be included in this UIFLOW version just like current one?

Paulskpt

Hi,
I just recently stepped into the 'world of M5Stack'. I am learning fast :-). Yesterday I published a small repo for M5Stack on GitHub and posted this fact in this Community forum. Thank you for your efforts to improve the firmware for M5Stack devices. The past ten years I experimented with Arduino, Raspberry Pi's (all models) , ESP32-S2. I prefer to write in Python but also built projects in C, C++. While trying to get aquainted to the M5Stack firmware I used REPL in Thonny to see which modules/functions are present in the several libraries. I discovered that there exist (at least appear in the dir() listings issued in REPL of Thonny). doubling of functions in the various library modules, for example: in 'vfs' exist: mount, umount, mkdir, chdir etcetera. These same functions also exist in the 'uos' module: mount, umount, mkdir, chdir and more. The module 'os' has the same contents as 'uos'. To me this is: a) confusing; b) if it are not a kind of 'links' (or say: 'redirection' -- my expression to this phenomenon) of a function in library 'x' to a function in libary 'y', then it will be a waste of memory too; c) this fact does not help to improve the quality and reliability of programs. I think that a function should be unique: be in one place only. This will also make writing and reading code more easy; helps preventing bugs and so on. But this is just a thinking on my side. I am not familiar with the internals of the current set of modules that make up the micropython firmware for the M5Stack family of devices. I started programming around 1978 with a 'computer' having only 64kB of RAM. Learning all kind of tricks, e.g.: re-use of RAM at runtime. If your intention is to 'optimize' the firmware you could start with a 'cleanup session' by taking out these confusing doublings. Question : is there a reason to have the same function in more than one library/module? This is just my first impression which I wanted to share with you since you asked: '...that you help us develop and test firmware...'
Regards,
Paulus Schulinck (@Paulskpt)