[Microbit-Python] Say hola to microperi [WIP]
Nicholas H.Tollervey
ntoll at ntoll.org
Mon May 16 03:47:45 EDT 2016
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.
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.
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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/microbit/attachments/20160516/3b689926/attachment-0001.sig>
More information about the Microbit
mailing list