Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

Godley
Copy link

@Godley Godley commented Sep 5, 2017

(which is free for open source projects)

@whaleygeek
Copy link
Owner

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
Copy link
Author

Godley commented Sep 6, 2017

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
Copy link
Owner

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
Copy link
Author

Godley commented Sep 9, 2017

(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
Copy link
Owner

whaleygeek commented Nov 17, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants