Can we make it clearer how people making accessories should support them in MicroPython?

[jaustin]

...using GitHub here, but please @ntoll redirect me if you'd like this in a different forum. Ultimately aiming for visible/public enough

One of the questions we (at micro:bit Foundation) get a lot in relation to the Python Editor and MicroPython in general is "How can I make a library to support my accessory?". At the moment, people tend to publish example code (hex files) and go from there.

Our current 'single file' model makes it hard to do much else, as far as I can see.

So I think there are two questions

1. Given the current state of play, what's the best advice for someone wanting to write python code to support an accessory with micro:bit - IE what should we ask them to provide for MicroPython?

2. What can/should we do in the future to improve this?

[ntoll]

This is as good a place as any for this sort of discussion. :-)

To answer your two questions:

1. We should document it in the microbit-micropython.rtfd.io based documents. I want to rearrange our docs so they're better signposted and delineated (here's the tutorials, here's the API, here's the how-tos etc...). This will, of course, take time and be the result of a best-effort voluntary exercise.

2. We should do what the PyBoard does. Provide enough of a USB mountable filesystem for files. My experience with the way the micro:bit currently works is that it's confusing how it "pretends" to be a USB based FS when it's not. Adafruit's Circuit Playground Express does a great job of working in a simple and effecting way in this regard. It'd be wonderful if micro:bit2 worked in the same way.

[jaustin]

1. We should document it in the microbit-micropython.rtfd.io based documents. I want to rearrange our docs so they're better signposted and delineated (here's the tutorials, here's the API, here's the how-tos etc...). This will, of course, take time and be the result of a best-effort voluntary exercise.

I agree with the where of your (1) but I was more asking for the "what". In the first sentence above, I'm not sure we have a clear version of "it" - IE do we say "write an example program" or do we say "write a Python module and then include it by doing..." or "write a class and paste it in the main file", etc, etc. How do we encourage people to combine these sanely when using accessory A and accessory B, for example!

We should do what the PyBoard does. Provide enough of a USB mountable filesystem for files. My experience with the way the micro:bit currently works is that it's confusing how it "pretends" to be a USB based FS when it's not. Adafruit's Circuit Playground Express does a great job of working in a simple and effecting way in this regard. It'd be wonderful if micro:bit2 worked in the same way.

I want to scope this to the existing, concrete stuff, but you're right the PyBoard and CP work really nicely :).

For micro:bit, sticking to the concrete/achievable I think that means a single hex delivery to the micro:bit. What could we do soon that might help this? Is it just allow multiple files in the online editor so you can drag/drop 'modules' in? Or have a simple mechanism of concatenating modules into the main.py?

[dpgeorge]

Given the current state of play, what's the best advice for someone wanting to write python code to support an accessory with micro:bit - IE what should we ask them to provide for MicroPython?

There are currently 2 options:

1. write a self-contained class for the peripheral/accessory that can be cut-and-paste into main.py (author of the class should also provide some simple example uses of said class);
2. do what Python was designed for and make a module with the functionality, and then copy this file to the microbit's filesystem; it already has this capability but I don't know how easy it is to work with the filesystem using Mu (or otherwise).

What can/should we do in the future to improve this?

I think a good solution (given that we can't really use the KL26 support chip) is to improve and merge the functionality of the internal current filesystem and the append-script-to-hex-file workflow. Ideally we'd have the following: you get a .hex file with "bare" MicroPython, ie no main.py or anything. Then you append all your files (which could be modules or data) to that .hex file (this would be done by Mu, I guess). Then when the code loads and runs the remaining flash is used for a dynamic filesystem. The filesystem that the user sees contains all the appended files, plus anything from the dynamic FS. This way, if the user appends, say, motor.py, then they can do "import motor" and it'll work as expected.

On the Mu side of things (if Mu can afford such complexity!) it could be like a simple IDE where you list all the files that are part of your project (eg main.py, motor.py, somedata.txt) and they are automatically added to the bare .hex file, which can then be downloaded to the device.