whaleygeek / bitio

A micro:bit I/O device library for Python
Other
92 stars 31 forks source link

Work In Progress: push to pypi via travis ci #18

Open Godley opened 7 years ago

Godley commented 7 years ago

(which is free for open source projects)

whaleygeek commented 7 years ago

Thanks for this, I'll use this as a basis for creating a pipy uploader. But there are some things about this that are wrong at the moment (breaking changes such as I want it to work using this style...

import microbit

And I need to think of the best way to package it to maintain that usage style.

Thanks for your suggestions!

Godley commented 7 years ago

cool. Is this abstracted enough that you could use the library from a laptop connecting to the microbit or are there elements that can be on the microbit but not on a laptop/vice versa?

whaleygeek commented 7 years ago

The abstraction is sufficient, but incomplete. i.e. in theory anything you can do on the micro:bit, you just run on the host with 'import microbit' and it will work. There are aspects that I have not implemented yet, but when I have, the API will be complete.

There is a small proviso about the gesture sensing though - it's cooperatively scheduled on the micro:bit and has to be called regularly for it to work. So even on the micro:bit itself, if you don't call get_gesture often enough (e.g. a long main-loop time) it doesn't perform well. So you need to poll quickly (your host mainloop time needs to be fast) for gestures to work.

Under the bonnet it uses the MicroPython raw REPL, so it essentially is a deterministic command and response transfer system and doesn't have to do any special parsing, but essentially it 'types in' the command and gets the response back.

So, like any proxy/abstraction, there are always system limitations, but it's good enough for the sorts of projects we're likely to use it for.

Godley commented 7 years ago

(The reason behind my question was because I was wondering if there were parts you could split out to use as a pypi library and parts which could remain as they are, but doesn't seem like that's the case).

whaleygeek commented 4 years ago

I will revisit this soon, as I want to decide how to support radio and neopixels, but to get the same import style as is used on the micro:bit, I'm still pondering what the package name will be in setup.py and on PiPy (as it will essentially offer multiple (but interlinked) packages in a single pip install.

i.e. 'pip install bitio' would install a microbit package, a neopixel package, and a radio package. This is so that users who already write code like this on micro:bit (or users who start with bitio and migrate 'in to' the micro:bit later) can get a seamless transition experience.

import microbit
import radio
import neopixel
...

neopixel and radio will be tightly coupled to the microbit module, as it is through the raw REPL interface inside that module that they will interact with the real micro:bit device.

If you have any view on how I might approach that @Godley I would be interested in your opinions and experience, thanks.