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

[WIP] Micropython support #92

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

Conversation

alxwrd
Copy link
Collaborator

@alxwrd alxwrd commented Aug 18, 2018

hello 👋 !!

This adds support for using l293d with Micropython.

Changes

  • I've stripped back the Config class, as it was using some features that Micropython doesn't support (__dict__, with_metaclass hacks). Now an instance of Config is created on module load, and __getattr__ and __setattr__ are class methods.

  • I've created a gpio submodule to handle loading in what to use for GPIO. This allowed me to make a wrapper for Micropythons machine that mirrors RPi.GPIO. I also added a testgpio that is used when nothing GPIO related can be imported (might be useful for Add tests to avoid problems like #61 #62).

WIP

Currently a work in progress as there are some things I need to figure out:

  • PWM works differently in Micropython, there doesn't seem to be a concept of 100% duty cycle (always on). The range is 0 - 1023, but I need to do some experiments with RPi.GPIO to see what it supports.
  • Documentation. I managed to scrape by with the current docs, and a pin diagram for my board. I don't know how good this can be though. I currently have an esp8266, but that's not the only supported board.
  • I'm not sure what to do about pin numbering. The current checks make sense for a Raspberry Pi, but might not for a different board. Should these checks be removed?

class method works with __setattr__ and __getattr__, so removing
the complicated metaclass
- collections is renamed ucollections in micropython
- threading isn't available on all ports of micropython
- __future__doesn't seem to be available, presumably because
   micropython code isn't meant to be ported between versions
@jmsv
Copy link
Owner

jmsv commented Aug 20, 2018

This is a great idea! I don't have experience with MicroPython so I'm not sure what to do about pin numbering etc. but I'm looking forward to seeing this develop 💯

@jmsv
Copy link
Owner

jmsv commented Oct 4, 2018

@alxwrd any progress? 😄

@alxwrd
Copy link
Collaborator Author

alxwrd commented Oct 4, 2018

😅 soon™

Just need to find some time to have a play with RPi.GPIO to see how I can get the PWM apis to line up.

I've just had some thoughts about fixing up the tests at least. I might jump on that now.

@jmsv
Copy link
Owner

jmsv commented Oct 4, 2018

Sounds awesome!

If needed we could refactor out calls to RPi.GPIO to our own interface and make the actual GPIO calls based on environment?

Are the tests specific to Micropython support or would that be a separate PR?

@alxwrd
Copy link
Collaborator Author

alxwrd commented Oct 4, 2018

Oops, sorry! I meant the test(s) failing for this PR. I still need to have a good think about testing in general.

With the gpio interface, that was my thinking with db5940d, it makes micropython behave like RPi. But yea, going foward might be good to look at a general interface for both.

@jmsv
Copy link
Owner

jmsv commented Oct 5, 2018

Missed that, oops - yep that's the kind of thing I meant. Looks cool ✨

Ah tests are looking better now, all 8 of them 😬 this package could definitely do with some more 😂 do you have any ideas for how we could test this new stuff?

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