MicroPython Forum (Archive)

I am extremely impressed and gratified by the development team efforts! MicroPython is an amazing piece of work.

Yesterday I upgraded my firmware development software (MicroPython 1.15, ESP-IDF 4.1) to MicroPython 1.19, ESP-IDF 4.4.1, using a clean installation. I'm very happy to see increasing new functionality for the ESP32 -- BUT, as expected, my code (pretty extensive, using multiple custom modules) has broken due to changes. I've read through the github releases posts for v1.16 through 1.19, as well as the analogous forum posts, and have not been able to figure out what has impacted the problems I'm seeing in my code. So, I have a few questions here:

(1) For some reason, now 'import os' (for example) doesn't allow one to access any os.<methods>, and instead I'm having to revert to 'import uos'. The former style worked in v1.15; what has changed to affect this? (this isn't a major problem and I can easily fix it)

(2) My larger-issue problem is that, due to hardware being unique, I had chosen the singleton approach to hardware-related classes, and classes that it makes sense to use only one instantiation for, in order to cleanly share global variables across many modules. Putting aside anyone's distaste for singletons, this approach worked for my project, and had no troubles while using v1.15. However, in v1.19, now I'm getting a "TypeError: 'module' object isn't callable" runtime error related to the @singleton decorator I've been using. For the record, the implementation I've been using is Peter Hinch's, from https://github.com/peterhinch/micropyth ... _singleton .
For some reason, if I have @singleton-decorated 'MyClass' defined in 'mymodule', importing the class via 'from mymodule import MyClass' and instantiating it in a different module _sometimes_ generates a runtime error (1 out of 3 runs, about). I'm having problems understanding why this error is occurring... For the record, I'm not an extremely experienced Python developer but have used my project to learn the language, especially the specifics relating to MicroPython. On occasion, I've had to rejigger CPython modules to work with MicroPython, and have had some success with that (for example, with 'datetime' module). However, I'm stumped here, and bothered that this error never occurred when using v1.15 but now occurs inconsistently, when it's difficult to know how to mitigate it.

Apologies for the long post! Perhaps this needed it's own posting thread, but I posted it here because it's directly correlated with my software upgrades. Thank you very much in advance for anyone who could give me some insight, and thanks again to all the developers, who have done such a fantastic job / labor of 'love'.

Hi again,
I'm also encountering another puzzling error, which may (?) be related to the type of error encountered in (2) of my post above.
Also, to note, regarding my software upgrade: I did _not_ install the official v1.19 release, but instead downloaded a copy of the github MicroPython 'main trunk' (I don't know github... using Subversion vocab).
The newly encountered error is: if, at the REPL, I execute:

>>> from module_name import MyClass

and subsequently instantiate the class with:

>>> myclassinstance = MyClass()

I am getting a "SyntaxError: invalid syntax". This was way puzzling, until I did an 'up arrow' in the REPL to repeat the command, and apparently what the MicroPython tried to interpret from what I typed in was:

>>> myclassinstance = MyClass(

(i.e., _without_ the trailing parenthesis). So, obviously, if that's what the interpreter saw, it's going to give a syntax error. The question is: WHY? The same problem also occurs for functions imported from modules.
However, if I so something like:

>>> from module_name import MyClass as MC
>>> mc = MC()

that _usually_ works! So, does this have something to do with the variable length?
I know that the terminal program I'm using is working and not cutting off the last character(s), because (a) it worked under v1.15 (per previous post) and (b) the characters appeared in the REPL when I typed them.

Again, stumped here...

By the way, apologies to the forum, but... the inconsistent REPL-interactive behaviour I was encountering per my last post seems to have been alleviated by erasing the flash memory and reflashing, so something in the firmware probably got written incorrectly... At any rate, if anyone else encounters similar issues, this might be a reason.

Also, just discovered:
Is 'uasyncio.gather' missing from the latest version of the MicroPython repo? It is not showing up when I import it...

No, uasyncio.gather is still there. Something seems to be wrong with your installation.

The rp2 port now has optional USB MSC support, and optional dupterm support

.

Is there a pi pico w build somewhere with these optional features turned on, or is there another way to enable them? Do we need to edit a cfg and compile a build?

I was using the Arduino nano connect rp2040 build in that device and had both of these features. I'm trying to get the same code working on the pi co now, but running into no dupterm in the os module.

Thanks!

Indeed, dupterm is only enabled on device with network support, and MSC only for the Arduino Nano Connect device.
You may have to use a daily build to get dupterm at Pico_W.

vlasoveqn wrote: ↑

Sat Aug 20, 2022 11:56 pm

(1) For some reason, now 'import os' (for example) doesn't allow one to access any os.<methods>, and instead I'm having to revert to 'import uos'. The former style worked in v1.15; what has changed to affect this? (this isn't a major problem and I can easily fix it)

This is mysterious and I'm not sure why this would have changed from 1.15 to 1.19. Do you have a custom os.py on the filesystem?

@jimmo I am convinced there is something wrong with @vlasoveqn 's installation. He can't access uasyncio.gather which implies an ancient version of uasyncio, he's having problems with my @singleton decorator which is bog standard Python; the uos problem is also baffling.

@vlasoveqn My approach would be to erase flash and start from scratch, re-testing each of these issues.