[Dprglist] MicroPython on the ESP32 (Robot News 3/3)

[Murray Altheim]

Hi,

Here's the third installment of Robot News.

---------------------------------------------------------------------------

Seon RosenBlum of Unexpected Maker is the developer of the TinyPICO and
the FeatherS2, both ESP32-based microcontrollers. The TinyPICO currently
can run MicroPython but the FeatherS2 only CircuitPython.

In a correspondence with Seon he indicated that MicroPython for the
FeatherS2 is "almost ready" and he's currently testing firmware for an
alpha release fairly soon. He'll be announcing it on his Discord channel,
which you can sign up for from his home page at:

   https://unexpectedmaker.com/

I'm still waiting for my TinyPICO and FeatherS2 boards in the mail but
have been playing with MicroPython on the Raspberry Pi Pico. The Pico
has been somewhat of a struggle. It supports MicroPython using either
the Thonny IDE or via rshell:

   https://github.com/dhylands/rshell

I'm a command line person and have been successfully using rshell, but
it's clear that the world of MicroPython is still rather new and
challenging territory.

For example, there is micropython-lib, "a project to develop a non-monolothic
standard library for "advanced" MicroPython* fork. Each module or package is
available as a separate distribution package from PyPI." The home page is at:

   https://github.com/micropython/micropython-lib

* https://github.com/pfalcon/micropython

...but this is hardly straightforward. *All* of the common libraries one gets
used to in Python3 are entirely absent in a MicroPython environment until you
install them, and there's a upip (corollary to pip/pip3) package emanager
for installing libraries, but I've not been able to get it to work at all so
far, and have been hand-installing some of the basics -- hard-going. I've got
logging and threading and itertools and a few others, and while I've managed
to get some trivial stuff running it's clear that I'll need upip or some
kind of package management for any sizable project (such as my ros project,
which has dozens and dozens of libraries), with pip3's dependency management
handling the stuff I don't even know about (or want to).

I have found out that the I2C slave functionality for MicroPython is either
not yet available or never will be, unsure who to believe on that one. I'd
tried to code up an I2C master-slave between a Pi and a Pico and while this
works in C I don't think it's yet possible in MicroPython using any existing
library -- you'd be on your own, bit-banging, but the I2C support currently
in MicroPython only seems to configure a master, not a slave. I'm hoping
that Seon has heard of something (as while he doesn't himself claim to
be a Python wizard he's well-connected in the Python community).

I'd kinda hoped this would be something "easy". I *may* be able to develop
a master-slave functionality over SPI, but I'll keep whacking my head against
the wall using I2C until it's clear there is no solution or I'm incapable
of finding it, whichever happens first... This whole idea of a Pi-master,
microcontroller-slave remains curiously elusive, particularly in Python.

So if I was trying to replace my Raspberry Pi with a MicroPython-based
microcontroller (like the FeatherS2), while it's possible to "port" some
of the functionality of my robot operating system, I'd likely lose some
very significant functionality, as many of the core Python3 libraries
will either be difficult to impossible to support in MicroPython unless
I port them myself or are able to find them in micropython-lib (which is
only a subset of Python3), and the proprietary (but open source) support
libraries from the likes of Adafruit and Pimoroni would have to be hand-
installed and possibly debugged/dependency-managed to get them running.

Is all this worth it? Hmm. Dunno.


# Asynchronous Message Bus .....................................

So my plates kinda full lately. I've *almost* got my asynchronous message
bus to the point where I can start plugging actual devices into it rather
than mocked versions of things, so that'll be my motor controller and the
Integrated Front Sensor. If I didn't mention it, this code would form a
significant component of my take on a subsumption architecture.

And if I can keep it significantly generic I might try pulling it out as
a separate library and learning how to publish a Python library so it can
be installed by anyone. A good learning exercise I'm sure, but the amount
of time to make something suitable for public consumption is at this point
a bit more than I can manage.

My basement flooded last week after a heavy rain so there are other things
commanding my attention lately too.

Cheers,

Murray

...........................................................................
Murray Altheim <murray18 at altheim dot com>                       = =  ===
http://www.altheim.com/murray/                                     ===  ===
                                                                    = =  ===
     In the evening
     The rice leaves in the garden
     Rustle in the autumn wind
     That blows through my reed hut.
            -- Minamoto no Tsunenobu