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

[Nicholas H.Tollervey]

Hi,

On 12/10/15 22:59, Damien George wrote:
> Yes, I think we need some direction and goals to get uPy on the
> microbit to a "v1.0" state.
> 

Exactly. Something to aim for, and given that we're (hopefully) going to
be working in the open very soon it'd be good to have this specified in
some way.

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

I agree... it's just important that we're clear and frame what we intend
to achieve so that as we attract more contributors they have an
easy/obvious path to finding out what we're up to.

>> * 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.
> 

I'm going to be playing with this today. ;-)

>> * 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.
> 

Larry, would it be possible to write up how you see this API working?
Something along the lines of the work I did for the music API (here:
https://github.com/dpgeorge/microbit-micropython/wiki/music-API) perhaps?

>> * 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.
> 

+1 It'd be great to take Mark's work and add Mariia's 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:
> 

Yes please. It also differentiates MicroPython from the other solutions.

> 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!).
> 

Cutting and pasting bytes... I like it. If this is documented in
baby-steps fashion then it's certainly suddenly a lot more accessible.

> 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?
> 

I like this too. Take a look at this - http://peter-cockerell.net/aalp/
from 1987!!!! My first programming language was BBC BASIC.

Can we do both. My reason for asking is that there appears to be a clear
progression from the inline assembler to the cut'n'paste bytes solution.

Both have a geeky "that's cool" aspect to them and reveal the
machinations of the device at quite a fundamental level which is also
cool from an educational perspective.

> 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).
> 

Yes... micro:bit = first step on a journey.

> 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).
> 

So this makes me wonder about documentation for the device /
MicroPython. It's all very well having all this cool stuff, but if it's
not explained then people won't use it. I've thoughts on how we tackle
this and will post them soon.

>> * 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...).
> 

I'll answer David separately.

>> * 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...).

I think it would be another great differentiator for MicroPython. It's a
generic means of displaying data. Given that the device will likely be
used as a sensor it makes sense to be able to quickly draw a bar graph
or realtime "equalizer" with cool fading effects.

As always, comments, constructive critique and ideas most welcome!

N.

> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
> 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://mail.python.org/mailman/private/microbit/attachments/20151013/2d70fb4b/attachment.sig>