[Microbit-Python] Say hola to microperi [WIP]
M.-A. Lemburg
mal at egenix.com
Mon May 16 05:57:25 EDT 2016
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/
More information about the Microbit
mailing list