[Feature] Enabling other MicroPython features

[laurensvalk]

We currently have most MicroPython modules and some features disabled. This is because we started on Move Hub, which does not have a lot of space (~106Kb). The other hubs have more space (~232Kb), so they can have more features enabled.

This issue is to collect ideas and suggestions from the community for modules and features we should enable.

[XilefTech]

have u forgotten the EV3 Hub or isn't this meant for it?

[laurensvalk]

have u forgotten the EV3 Hub or isn't this meant for it?

No, I didn't mean to suggest that 😄

EV3 has nearly infinite memory and SD Card flash space compared to these hubs, so it has all of these features enabled already.

[XilefTech]

oh okay, makes sense

[dlech]

A while ago, someone mentioned enabling slicing. This increases frimware size by 4K, so it is quite expensive in that regard. But not out of the question if there is high demand.

[dlech]

Some other available builtins:

• bytearray
• filter
• property
• reversed
• set
• memoryview
• additional string methods

Some available modules:

• uarray
• ubinascii
• ucollections
• ucmath
• uio
• uos
• ure
• ustruct
• uheapq
• utimeq
• usys
• uselect

[laurensvalk]

A while ago, someone mentioned enabling slicing.

@dracode: we've made some major steps forward with Pybricks recently, so now might be the time to give it another try, and review the feature set if you like.

[laurensvalk]

I think we may want to consider the gc module or, if not that in full, some other way to see how much free memory there is.

Available memory appears to be a contentious topic of discussion in the SPIKE Prime community, so this could help make that more specific, and control over the gc might help in certain applications.

@devinbreise requested it here, in this case for EV3.

[dlech]

some other way to see how much free memory there is.

FYI, this is already possible.

import micropython

micropython.mem_info()
micropython.mem_info(1)  # shows memory map in ascii art

[TechnicBRICKs]

I can't say about modules as I'm really newbie to Python, but definitely would like to see included some library that would enable inter-hub BT communication.
My idea is to become able to control additional remote ports from a master hub. Something like daisy chaining in EV3 (although wired in that case).

[laurensvalk]

This issue is more about features available in the MicroPython language upon which Pybricks is built.

For specific features to Pybricks, such as wireless communication, it would be better to open a separate issue so we don't forget about it.

[krimhild58]

Hmm, ubluetooth is a micropython fearure isn’t it? I would be very much interested in that. Especially as the new hubs are essentialy disconnected from all lego specific communication without it. Can‘t use lego remote, can‘t use lego app, can’t interact.

[BertLindeman]

Also with the misleading error messages in issue #217 in mind I would vote for slicing enabled.

[mwinkler]

I'm also interested in the 'ubluetooth' module. Mainly to connect with a remote control (eg. the new xbox series x controller with BLE) or a ESP32 (for example).

[Vinz1911]

I'm not sure If ubluetooth will work great on the small lego hubs, this is a heavy library. I worked with that library on a spike prime and I often run into memory problems with that until the last two firmware upgrades (I think lego has a bit optimized memory management or the base system consumes less memory). And it only works good as optimized pre-compiled lib which is copied to the hub. The resources on the other lego hubs are much smaller and I'm not sure if this will work as expected

[mwinkler]

I got now a xbox controller with BLE support. Service and characteristic discovery works, but I am stuck now.
The problem is, that I'm unable to pair with the device, because the function "BLE.gap_pair" is missing in the original prime firmware.
Maybe as input for the bluetooth revising.

[Vinz1911]

Does it not work with .gap_connect ? Is .gap_pair necessary for that ? This is part of a newer version of Micropython, which is not yet released for the prime hub :/

[mwinkler]

Ok good to know.
.gap_connect works (then receiving the services & chars), but the connection indicator light on the pad keeps blinking and I receive no GATTC_NOTIFY events. So i assume there is pairing needed. Maybe you have idea?

[laurensvalk]

Thanks @mwinkler and @Vinz1911 --- would you mind discussing this in #191 instead? Thanks!

[antonvh]

I would like to see a Neopixel module (ws2812) LED drivers. This has to be done natively because python is too slow to create the 2microsecond pulses.

[antonvh]

I would like to have the @micropython.asm_thumb enabled.

@micropython.asm_thumb
def fun():
   movw(r0, 42)

[antonvh]

Maybe this will be part of hub2hub, but some kind of RPC (remote procedure calls) would also be nice on top of data transfer.

OpenMV has an implementation, but I don't know how general that is: https://docs.openmv.io/library/omv.rpc.html

[antonvh]

On top of basic hub2hub data connections, a communication layer that handles buffers, waits, packing, unpacking, pickling, encode, decode, etc... would be really helpful. Preferably a solid, efficient, real-time data protocol with retention of Python typing.
Microbit broadcast is a good example.
Something like oatmeal is interesting too: https://pypi.org/project/oatmeal/

[novakasa2]

ujson would be a nice addition to pass more complex data when communicating with a PC

[dlech]

* bytearray

This would allow us to use readinto() (e.g. for stdin) to avoid extra memory allocations and help prevent fragmentation.

[laurensvalk]

A while ago, someone mentioned enabling slicing. This increases frimware size by 4K, so it is quite expensive in that regard. But not out of the question if there is high demand.

The delta on today's firmware seems to be only 104508-103324 = 1184 bytes, so it isn't nearly as bad anymore, so we should be able to enable it under PYBRICKS_STM32_OPT_EXTRA_MOD at least.

[laurensvalk]

Thanks for the suggestions everyone! Quite a few of these are now enabled and we are in the process of documenting them as part of the V3.1 release in #286.

A few comments were made about hub-to-hub communication as well. We won't be enabling ubluetooth, but we're looking at a simple but effective serial stream over BLE. That's the aim of the V3.3 release.

Feel free to open a dedicated issue for each feature you still think would be worth having.