[Microbit-Python] Say hola to microperi [WIP]

[David Whale]

Joe/Andrew, just one point of style.

Is there a reason you called it microperi, rather than just calling it
microbit? Really it is a microbit, isn't it, because you are talking to the
microbit. It seems a shame to introduce another name, when the existing
name will do fine?

The reason I called my original August 2015 proof of concept 'microbit' is
so that the same code you would run on the micro:bit itself could be copied
and run on a Pi/PC/Mac *unmodified*, and it would essentially function the
same, but the actual sensing and output would happen on the micro:bit
rather than on the Pi/PC/Mac. You can then start to enhance the code on the
Pi/PC/Mac to use additional non microbit libraries.

I particularly thought that this mode of use would be a really good
progression, to transition children up from the micro:bit to bigger
platforms and give them more power (while bringing forward all their
existing understanding about learning MicroPython on the micro:bit and
allowing them a period of using both devices together in harmony.


A couple of other thoughts:

Raw REPL sounds good, it'll save mucking about with filtering out the
echoback, which will simplify the link manager somewhat. Also it means (as
Damien points out) you can send multiple lines, which could be useful in
some cases to synthesise things that are harder to write with a single line
of MicroPython code, e.g. such as if you want to wrap exception handlers
around the code on the micro:bit end to improve the error handling.

Don't forget that you could get your host code to dynamically define some
functions inside MicroPython on the micro:bit to improve the handling of
certain error cases, and this would still mean that you flash a vanilla
MicroPython into it and all the intelligence is still in the host code
(making it very easy to deploy to any micro:bit).

Have you spoken to the Raspberry Pi foundation about this, I spoke to them
months ago and they were interested in this idea, but you should raise it
with them again, as they might consider including the code in the standard
distribution once it has stabilised. RaspberryPi + micro:bit is a really
good combination (especially if you run Python on both!)

You could consider doing a file copy from the host code, to actually upload
the MicroPython.hex file into the micro:bit for you (the .hex could be
embedded inside your host module) so that you can just 'run and go' - I use
this technique in some of my arduino/pi projects, where the python on the
Raspberry Pi loads the firmware into the arduino first and then talks to it
over serial, making the whole setup seamless for the user and single step.
You could always have an option in the host code to urlfetch the .hex from
the web if you don't want to always distribute it inside your package.

P.S. for completeness, here is the work that Martin and I did on the
Minecraft xwing - recoding this using this new technique will be great fun!

http://www.stuffaboutcode.com/2015/12/minecraft-microbit-and-x-wing.html

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20160516/0b4af47f/attachment-0001.html>