-
Notifications
You must be signed in to change notification settings - Fork 32
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
base: master
Are you sure you want to change the base?
Conversation
think the deploy part of the travis config does everything else for you
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...
And I need to think of the best way to package it to maintain that usage style. Thanks for your suggestions! |
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? |
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. |
(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). |
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.
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. |
(which is free for open source projects)