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

Joe Glancy joe.t.glancy at gmail.com
Mon May 16 08:54:08 EDT 2016


The name is a combination of "micro" and "peripheral", because that's
essentially what the micro:bit becomes.

Yeah, raw REPL will be the next thing to implement - the current exception
handler looks for the string "Traceback" in every line of output, and then
grabs the name and message of the exception and re-throws it. This means
you get the same exception that the micro:bit throws, but you don't get the
original stack trace. Adding exception handlers could help, but the
exceptions will still just be processed and the user will get to same
outcome.

I have not, might be something to tweet to them about - they certainly do
make a great combo, especially for schools.

That would add ~0.5MB to the module, quite a sizeable amount - it would
probably be easier for the teachers to download an empty script from the
online IDE and copy + paste it into the micro:bit's virtual drive.
Downloading it from online would require an internet connection, which they
might not have (zero install). It'll also take a while to flash it every
time you want to use the device.

On Mon, 16 May 2016, 13:14 David Whale, <david at thinkingbinaries.com> wrote:

> 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
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20160516/33caa53a/attachment.html>


More information about the Microbit mailing list