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

Sun May 15 08:21:01 EDT 2016

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