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

David Whale david at thinkingbinaries.com
Sun May 15 11:13:13 EDT 2016 

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> 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>
> 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> 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>
>>> 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> 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
>>>>> 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
>>>
>>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20160515/c7a66ac5/attachment-0001.html>

More information about the Microbit mailing list