[Microbit-Python] Current state of play - a summary and straw man

[Damien George]

Yes, I think we need some direction and goals to get uPy on the
microbit to a "v1.0" state.

We've had a lot of good ideas, discussion and contributions.  I think
we are close to having a very usable API.

> * Music API - first draft of Matthew's native API is merged into master.
> Requires further development to allow it to work in the background. I'll
> be adding musical examples over the course of this week and testing it
> from a musician's perspective.

I think the music module is wonderful.  It's so easy at the REPL to do:

music.tune(pin0, ['c', 'd', 'e', 'f', 'g', 'a', 'b', 'c'])

or even:

music.tune(pin0, [chr(ord('c') + i) for i in range(8)])

or better still:

music.tune(pin0, list('cdefgabc'))

Yes it needs work to have non-blocking mode.  And builtin tunes would
be awesome.

> * Larry's game related work - I think this is hugely important. Kids
> love games and showing off their work to each other. If we can make it
> super easy to facilitate such hacking then we're doing something
> marvellous.

Yes, it's great to have Larry's experience with game writing to make a good API.

> * Marks' image related work - again, this is hugely important because
> being able to see the result of your code is a great inspiration to
> kids. The easier and more capable we make this the better it'll be for
> all concerned.

Yep.  Even with the additional features added here, we still have a
really easy entry point to simply scroll a message or animate a
sequence of images.

> * Damien's suggestion of inline assembler which sounds like it'd be a
> wonderful thing for the hacker/maker audience the BBC are also hoping to
> tempt as a secondary market.

I can add this if we think it'll be attractive.  There are 2 options:

1. A simple "machine_code" function that takes raw bytes and turns
them into a function.  Very hard to use, eg: fun =
machine_code(b'\x12\x34\x56') and you have to find out the correct
byte values by assembling offline with an arm assembler, then looking
at the output.  Really hard to use (but then that might give it a cool
factor!).

2. The proper inline assembler that already exists, where you write code like:

@micropython.asm_thumb
def f(r0, r1):
    label(loop)
    add(r0, r1)
    bne(loop)

This is easier to hack, but since it's verbose you'll run out of
memory (in the compile stage) if you try to write long functions.  It
also takes up flash space (not too much though) and maybe in the
future we need this flash space for other things?

Regarding attracting the hacker/maker audience: I think it's important
to point out that starting with the microbit is an entry point to
learning MicroPython, and then people who want more can buy a more
capable board that runs uPy (eg pyboard).

Oh, and uPy on the microbit also supports I2C and UART interfaces, for
those that want to interface with other electronic components (temp
sensors, etc).

> * David's MIDI related suggestions. I'm not clear what would be involved
> for this - I presume we could use USB/serial to send MIDI information to
> a MIDI device running elsewhere. David, it'd be helpful to learn how you
> see this working.

I don't have any experience with MIDI, so also don't see how this
would work (and can't really test it...).

> * Damien and I discussed turning the display into some sort of generic
> graphical equaliser for arbitrary data.

It would be neat, but I think this would be a lower priority (unless
the BBC really likes the idea...).