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

Damien George damien.p.george at gmail.com
Mon May 16 07:25:16 EDT 2016


Joe & Andrew: great work!  But did you know about raw REPL mode?  If
you type ctrl-A at the REPL then it goes into this mode which is like
the normal REPL but does not echo characters back.  It also requires
you to send ctrl-D to finish the input (and thus you can enter
multiple lines, even blank lines, as part of your input).  Raw REPL
mode is used to talk to MicroPython from a PC, so is exactly what you
want!

On Mon, May 16, 2016 at 12:12 PM, David Whale
<david at thinkingbinaries.com> wrote:
> Joe, I like what you did there!
>
> https://github.com/JoeGlancy/microperi/blob/master/microperi/microperi.py#L20
>
> Great stuff.
>
> Zero install, if possible, is always the way to go!
>
> David
>
>
> ___________________________________________________________
> David Whale, B.Sc (Hons), MIET
> Software Engineer and IET Schools Liaison Officer, Essex
>
>
> On 16 May 2016 at 11:59, Joe Glancy <joe.t.glancy at gmail.com> wrote:
>>
>> Yeah, pretty much every school uses Windows (I think most often it's
>> Windows 7?).
>>
>> Thanks for the tip David - microperi is now completely portable and
>> requires 0 installation (plus very little effort).
>>
>>
>> On Mon, 16 May 2016, 10:57 M.-A. Lemburg, <mal at egenix.com> wrote:
>>>
>>> On 16.05.2016 09:47, Nicholas H.Tollervey wrote:
>>> > For the Mu editor Carlos did some amazing work in automatically
>>> > building
>>> > a stand-alone executable for Windows, OSX and Linux.
>>> >
>>> > Of course, Windows will complain if you try to run a stand-alone
>>> > executable and warn you to the extent that you'll imagine the world is
>>> > about to end, but there you go.
>>>
>>> Why is that ? Because you are accessing the serial port ?
>>> I think you can get (at least partially) around this by signing
>>> the executable.
>>>
>>> > Unfortunately, the real problem (the way schools organise their IT) is
>>> > impossible for us to fix. Ergo all this faffing about. Nevertheless,
>>> > it's worth it when teachers and kids get their hands on the good stuff.
>>>
>>> Am I right in assuming that most schools use Windows for their
>>> (kids) PCs ?
>>>
>>> > Best wishes,
>>> >
>>> > N.
>>> >
>>> > On 15/05/16 16:13, David Whale wrote:
>>> >> Hi Joe,
>>> >>
>>> >> Yes, but the way we typically do this is to unzip the package
>>> >> directory
>>> >> into the users project directory. That's how I do it with the anyio
>>> >> library I wrote for my minecraft book, and that's ow the original
>>> >> mb_remote works.
>>> >>
>>> >> i.e. if the user project directory is my_awesome_project
>>> >> ...and if there is a file my_awesome_project/test1.py
>>> >> ...and if there is a folder my_awesome_project/microbit
>>> >>
>>> >> ...then when you import microbit in test1.py, it all works.
>>> >>
>>> >> The embedded serial folder inside the microbit folder (with it's magic
>>> >> sys.path modifier) just makes it all work seamlessly.
>>> >>
>>> >> It really is very simple to use.
>>> >>
>>> >> Lines 28..33
>>> >> here:
>>> >> https://github.com/whaleygeek/mb_remote/blob/master/src/microbit.py#L28
>>> >>
>>> >>
>>> >> Teachers hate it when you have to run install scripts and need admin
>>> >> access, because (a) it means you have to beg to the IT technician
>>> >> which
>>> >> sometimes takes months (literally), and (b) it means that they have to
>>> >> consider which machines are configured correctly and which are not.
>>> >>
>>> >> If all you have to do is unzip a folder and start coding, it's
>>> >> *really*
>>> >> simple. They can even give the instructions to the kids and they can
>>> >> just unzip the file into their user directory and it all works
>>> >> seamlessly.
>>> >>
>>> >> In one school, it took the technician 3 months (of continuous teacher
>>> >> begging) to get python installed, just so they could run the GCSE
>>> >> controlled assessments.
>>> >>
>>> >> David
>>> >>
>>> >>
>>> >> ___________________________________________________________
>>> >> David Whale, B.Sc (Hons), MIET
>>> >> *Software Engineer and IET Schools Liaison Officer, Essex*
>>> >>
>>> >>
>>> >> On 15 May 2016 at 13:21, Joe Glancy <joe.t.glancy at gmail.com
>>> >> <mailto:joe.t.glancy at gmail.com>> wrote:
>>> >>
>>> >>     That's a good point - embedding pyserial would certainly make it
>>> >>     more portable, as it doesn't depend on anything else except
>>> >> standard
>>> >>     modules then. The only (small) limitation with a zero install is
>>> >>     that scripts would have to be in the same location as the module's
>>> >>     directory, but that's hardly an issue.
>>> >>
>>> >>
>>> >>     On Sun, 15 May 2016, 10:42 David Whale,
>>> >> <david at thinkingbinaries.com
>>> >>     <mailto:david at thinkingbinaries.com>> wrote:
>>> >>
>>> >>         Joe and Andrew,
>>> >>
>>> >>         Just a comment about this, please read this article, and
>>> >>         consider *changing* how you package this, especially for
>>> >> teachers:
>>> >>
>>> >>
>>> >> https://codeboom.wordpress.com/2016/05/11/scratch-is-the-new-powerpoint/
>>> >>
>>> >>         The version that I wrote back in August 2015 is zero install -
>>> >>         yes, ZERO install. All a teacher has to do is to press the
>>> >>         DownloadZip button, unzip it, and run it. This is VITAL for
>>> >>         teachers to use these resources, especially on a Raspberry Pi
>>> >>         where mostly they are not connected to the internet most of
>>> >> the
>>> >>         time. Most of the time they want to just grab a file on a USB
>>> >>         memory stick, and copy it over. sudo pip install is *useless*
>>> >> in
>>> >>         this situation.
>>> >>
>>> >>         Raspberry Pi's are mostly not connected to the internet in
>>> >>         schools, because it stores the wifi password in plain text in
>>> >>         the config file, and school IT technicians ban the teachers
>>> >> from
>>> >>         using them for this reason (as it exposes the password to the
>>> >>         kids, and then all their phones start connecting to the wifi
>>> >> and
>>> >>         makes it crash). Really, this is a big problem, believe me!
>>> >>
>>> >>         The way I did this was to *embed* pyserial into the package
>>> >> (and
>>> >>         the licence allows for this providing you are clear about the
>>> >>         containing licence). Please see my original
>>> >>         here: https://github.com/whaleygeek/mb_remote and you will see
>>> >>         this works really great. There is also a little bit of python
>>> >>         magic in the file (it modifies the sys.path inplace) to make
>>> >>         sure that this happens automatically. (you need to make this
>>> >>         Python 3 safe still, of course).
>>> >>
>>> >>         Can I strongly urge you to make it zero install? It'll get
>>> >>         adopted really quickly that way.
>>> >>
>>> >>         I've had a number of chats with teachers already about this
>>> >> and
>>> >>         they are really excited about it, but they said to me 'ah,
>>> >> it's
>>> >>         all that sudo pip stuff, that never works for us'. Lots of
>>> >>         teachers I speak to gave in with PyGameZero because they
>>> >>         couldn't get it to install.
>>> >>
>>> >>         Thanks
>>> >>
>>> >>         David
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>         ___________________________________________________________
>>> >>         David Whale, B.Sc (Hons), MIET
>>> >>         *Software Engineer and IET Schools Liaison Officer, Essex*
>>> >>
>>> >>
>>> >>         On 14 May 2016 at 22:54, Joe Glancy <joe.t.glancy at gmail.com
>>> >>         <mailto:joe.t.glancy at gmail.com>> wrote:
>>> >>
>>> >>             Thanks David :)
>>> >>
>>> >>             I'll see if I can find that demo and get it up and working
>>> >>             with this module - would be nice to have some examples
>>> >> with
>>> >>             it where it can interact with things such as MCPI straight
>>> >>             out of the box.
>>> >>
>>> >>             And indeed it does make an excellent addon, mostly thanks
>>> >> to
>>> >>             the pretty much universal serial interface it uses to
>>> >>             communicate (which allows it to be easily interfaced on
>>> >> many
>>> >>             platforms with minimal (or even none) setup required).
>>> >>
>>> >>             As a matter of fact, I thought up of something very
>>> >> similar
>>> >>             to this but which communicated over Bluetooth instead a
>>> >>             while ago (using a stock micro:bit image), with a
>>> >> Raspberry
>>> >>             Pi 3 and micro:bit as use case. Unfortunately, I found it
>>> >>             impossible to get the micro:bit to work properly with
>>> >> BlueZ,
>>> >>             despite some help from the BlueZ IRC and Linux Bluetooth
>>> >>             mailing list.This kind of lead to the wired approach you
>>> >> see
>>> >>             now. Maybe the recent BlueZ updates will fix this, so that
>>> >> a
>>> >>             wireless alternative to this module exists too.
>>> >>
>>> >>
>>> >>             On Sat, 14 May 2016, 22:25 David Whale,
>>> >>             <david at thinkingbinaries.com
>>> >>             <mailto:david at thinkingbinaries.com>> wrote:
>>> >>
>>> >>                 Looks great, Joe and Andrew!
>>> >>
>>> >>                 Yes, I wrote this original mb_remote version back in
>>> >>                 August 2015, but the Python API on the micro:bit
>>> >> changed
>>> >>                 many times since then and I've been too busy to
>>> >> maintain
>>> >>                 it. However, it's great to see this moving forward.
>>> >>                 There are some really nice use cases (especially
>>> >>                 micro:bit + Raspberry Pi) where this sort of approach
>>> >> is
>>> >>                 both really useful and great fun, as I discovered with
>>> >>                 my early tests.
>>> >>
>>> >>                 The 'flying xwing in minecraft with a micro:bit' that
>>> >>                 Martin and I did, was really the inspiration for me
>>> >>                 writing the mb_remote, more to get a feel for what it
>>> >>                 would look like than anything else. I had come to the
>>> >>                 conclusion that the micro:bit makes a great peripheral
>>> >>                 for other computers, what with it's onboard sensors
>>> >> and
>>> >>                 I/O pins, and having a really quick way to extend your
>>> >>                 python from the host PC onto the micro:bit is really
>>> >> fun.
>>> >>
>>> >>                 I'm also glad to see you take forward the idea of
>>> >> poking
>>> >>                 commands into the REPL and getting responses (that's
>>> >>                 much better than having to load custom firmware onto
>>> >> the
>>> >>                 micro:bit, as other solutions tend to go for).
>>> >>
>>> >>                 David
>>> >>
>>> >>
>>> >>
>>> >> ___________________________________________________________
>>> >>                 David Whale, B.Sc (Hons), MIET
>>> >>                 *Software Engineer and IET Schools Liaison Officer,
>>> >> Essex*
>>> >>
>>> >>
>>> >>                 On 14 May 2016 at 20:58, Joe Glancy
>>> >>                 <joe.t.glancy at gmail.com
>>> >> <mailto:joe.t.glancy at gmail.com>>
>>> >>                 wrote:
>>> >>
>>> >>                     Myself and Andrew (Mulholland, @gbaman on GitHub -
>>> >>                     credit to him for first starting this) have been
>>> >>                     working on something similar to David's mb_remote
>>> >>                     module for Python, called microperi
>>> >>                     (micro-peripheral, as that is what the micro:bit
>>> >>                     becomes :). It is currently (and very much) an
>>> >> alpha
>>> >>                     work-in-progress, and I'm only informing everyone
>>> >>                     here about it because we need testers and, more
>>> >>                     importantly, feedback.
>>> >>
>>> >>                     It lives at
>>> >> https://github.com/JoeGlancy/microperi,
>>> >>                     and because none of the install methods
>>> >>                     (pip3/python3 setup.py install) work properly as
>>> >> of
>>> >>                     now, the best way to try it is just create your
>>> >>                     scripts in the same directory where the docs
>>> >>                     (README, CONTRIBUTING etc) are and use `import
>>> >>                     microperi` (check out the example in the README
>>> >> for
>>> >>                     a bit of a better howto).
>>> >>
>>> >>                     It exposes almost all of the micro:bit's
>>> >> MicroPython
>>> >>                     `microbit` module, which is completely available
>>> >>                     through a microperi.Microbit object. This is
>>> >>                     actually one of the things that I'd like feedback
>>> >>                     about; see below for more information (I don't
>>> >> think
>>> >>                     I've explained this too well, but it's the best I
>>> >>                     could think of and word). If you just want to try
>>> >> it
>>> >>                     out, get cloning and give it a whirl. Anything you
>>> >>                     spot as a bug or something you feel needs to be
>>> >>                     improved/implemented, just create an issue or
>>> >> submit
>>> >>                     a PR (check CONTRIBUTING.rst first though).
>>> >>
>>> >>                     We decided on the Microbit object (instead of one
>>> >>                     pre-set object called `microperi.microbit`, which
>>> >> it
>>> >>                     actually was originally) so that multiple
>>> >> micro:bits
>>> >>                     can be used at the same time. The constructor is:
>>> >>
>>> >>                     microperi.Microbit(port=None)
>>> >>
>>> >>                     If port is not specified, the module will
>>> >>                     automatically detect the first available micro:bit
>>> >>                     and use that one (Nick, the finding code is from
>>> >>                     microrepl - could you comment on licensing
>>> >> please?).
>>> >>                     Otherwise, `port` must be a string determining the
>>> >>                     serial port which the micro:bit is connected to
>>> >>                     (e.g: /dev/ttyACM0, COM1, etc).
>>> >>
>>> >>                     Usual usage of the object is along the following
>>> >>                     lines (or, more literal, line):
>>> >>
>>> >>                     microbit = microperi.Microbit()
>>> >>
>>> >>                     and then things like the microbit.Image class are
>>> >>                     available through `microbit.Image`. However, if I
>>> >>                     were to call the micro:bit object a different name
>>> >>                     in my script (such as "uBit"), the Image class
>>> >> would
>>> >>                     be accessible as uBit.Image, which deviates from
>>> >> the
>>> >>                     MicroPython API. However, we did not want to place
>>> >>                     things like the Image & pin classes in somewhere
>>> >>                     like `microperi.microbit.Class_name` because then
>>> >>                     you'd have a bit of a mess like so:
>>> >>
>>> >>                     from microperi import *
>>> >>                     uBit = Microbit()
>>> >>                     solid = microbit.Image.SNAKE
>>> >>                     uBit.display.show(solid)
>>> >>
>>> >>                     because some things (e.g: microbit.i2c.read) would
>>> >>                     be accessible through `uBit.i2c.read`, and others
>>> >>                     (e.g: microbit.Image) would be accessible through
>>> >>                     `microbit.Image`, when they both should be under
>>> >>                     `microbit.X`, if you understand what I mean.
>>> >>
>>> >>                     The best solution for this currently is just
>>> >> calling
>>> >>                     the object `microbit`, and then everything will be
>>> >>                     as it should, but if you don't some things will be
>>> >>                     in different places.
>>> >>
>>> >>                     Anyway, I hope that this module will prove itself
>>> >>                     useful for people and perhaps even in the
>>> >> classroom,
>>> >>                     as it notably allows not only use of the microbit
>>> >>                     module but also every other Python 3 module out
>>> >>                     there, allowing much more powerful (possibly IoT
>>> >>                     integrated?) scripts to be created on a much more
>>> >>                     powerful machine. I look forward to any feedback,
>>> >>                     and hope for a proper, stable release (with
>>> >>                     documentation of some sort) sometime soon.
>>> >>
>>> >>                     _______________________________________________
>>> >>                     Microbit mailing list
>>> >>                     Microbit at python.org <mailto:Microbit at python.org>
>>> >>                     https://mail.python.org/mailman/listinfo/microbit
>>> >>
>>> >>
>>> >>                 _______________________________________________
>>> >>                 Microbit mailing list
>>> >>                 Microbit at python.org <mailto:Microbit at python.org>
>>> >>                 https://mail.python.org/mailman/listinfo/microbit
>>> >>
>>> >>
>>> >>             _______________________________________________
>>> >>             Microbit mailing list
>>> >>             Microbit at python.org <mailto:Microbit at python.org>
>>> >>             https://mail.python.org/mailman/listinfo/microbit
>>> >>
>>> >>
>>> >>         _______________________________________________
>>> >>         Microbit mailing list
>>> >>         Microbit at python.org <mailto:Microbit at python.org>
>>> >>         https://mail.python.org/mailman/listinfo/microbit
>>> >>
>>> >>
>>> >>     _______________________________________________
>>> >>     Microbit mailing list
>>> >>     Microbit at python.org <mailto:Microbit at python.org>
>>> >>     https://mail.python.org/mailman/listinfo/microbit
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> Microbit mailing list
>>> >> Microbit at python.org
>>> >> https://mail.python.org/mailman/listinfo/microbit
>>> >>
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Microbit mailing list
>>> > Microbit at python.org
>>> > https://mail.python.org/mailman/listinfo/microbit
>>> >
>>>
>>> --
>>> Marc-Andre Lemburg
>>> eGenix.com
>>>
>>> Professional Python Services directly from the Experts (#1, May 16 2016)
>>> >>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> >>> Python Database Interfaces ...           http://products.egenix.com/
>>> >>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
>>> ________________________________________________________________________
>>>
>>> ::: We implement business ideas - efficiently in both time and costs :::
>>>
>>>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>>>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>>>            Registered at Amtsgericht Duesseldorf: HRB 46611
>>>                http://www.egenix.com/company/contact/
>>>                       http://www.malemburg.com/
>>>
>>> _______________________________________________
>>> Microbit mailing list
>>> Microbit at python.org
>>> https://mail.python.org/mailman/listinfo/microbit
>>
>>
>> _______________________________________________
>> Microbit mailing list
>> Microbit at python.org
>> https://mail.python.org/mailman/listinfo/microbit
>>
>
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>


More information about the Microbit mailing list