Frozen python code as part of machine module? #8241

harbaum · 2022-02-01T08:56:34Z

I am implementing an alternative to #6639 which only does the very basic ESP32 PCNT API in C. The Counter and Encoder classes as decribed at #8072 are pure Python and subclassed from this PCNT API.

I personally think that such an approach is nicer and cleaner than the current approach. I thus would like to provide a full implementation of my approach.

But Encoder and Counter classes as described in the aforementioned documentation are part of the machine module. And I don't know how to add Python code to that. Is that possible at all? Can I add python code to the machine module to be frozen into the firmware?

I simply tried to add machine/Encoder.py to port/esp32/modules. But that does not work. It compiles but Encoder does not how up in the machine module.

dpgeorge · 2022-02-01T11:51:11Z

There is not a direct way to do this, to combine Python and C code in the same (built in) module.

But the idea with u-module naming is that the C parts can be implemented in, eg, umachine and then the Python parts wrap that up in the machine module. Eg machine/__init__.py will do from umachine import * and then add everything else. Effectively the C code is in a hidden module and the user visible module is written in pure Python. See uasyncio for an example of this.

See also #5025 for an idea of a way to implement built-in functions in Python.

harbaum · 2022-02-01T14:14:09Z

Understood, thanks for the reply. So there is currently no way to implement Counter and Encoder as documented in #8072 in Python.

I wonder if it then makes sense to put highlevel stuff like Encoder and Counter that into the machine module at all. On some plattforms without dedicated hardware counter this may actually be implemented on top of Pin.irq() which in turn can nicely be done in Python and would not require any C.

But anyway, then I'll happily support the somewhat bloated solution in #6639 . As said in the PR: Better that version than nothing.

harbaum · 2022-02-01T15:22:43Z

So i can achieve this by just changing

micropython/ports/esp32/mpconfigport.h

Line 237 in 1f04a9a

{ MP_OBJ_NEW_QSTR(MP_QSTR_machine), (mp_obj_t)&mp_module_machine }, \

to

MP_OBJ_NEW_QSTR(MP_QSTR_umachine), (mp_obj_t)&mp_module_machine }

and creating modules/machine/__init__.py as:

from umachine import *

This now copes with my little Encoder class quite nicely. But what are the chances, that such a patch would be accepted upstream? Also all other uXXXX modules use the u prefix interally for C functions and such as well. Would a proper patch renaming everything inside the esp32 port to umachine?

dpgeorge · 2022-02-02T05:08:26Z

But what are the chances, that such a patch would be accepted upstream?

I think it's a good change. Some ports already have umachine as the main name.

See #8244 for a patch that makes this change.

dpgeorge · 2022-02-02T23:31:45Z

umachine is now available as of fbd47fc

Fix RGB/BGR color order for Picopad

dpgeorge mentioned this issue Feb 2, 2022

ports: Consolidate include of umachine module in built-ins. #8244

Merged

dpgeorge closed this as completed Feb 2, 2022

tannewt added a commit to tannewt/circuitpython that referenced this issue Aug 1, 2023

Merge pull request micropython#8241 from MakerClassCZ/picopad-rgb-fix

aecaab7

Fix RGB/BGR color order for Picopad

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Frozen python code as part of machine module? #8241

Frozen python code as part of machine module? #8241

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Frozen python code as part of machine module? #8241

Frozen python code as part of machine module? #8241

Comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!