pimoroni-pico
pimoroni-pico copied to clipboard
Micropython examples are incomplete
Hi
I've tried getting the microPython examples running but there are always missing libraries and the instructions are not there to get someone started easily.
I've tried following the C examples, but even just getting the environment up and running is much harder with C
I appreciate you've probably all got a lot more experience than me, but I'm trying to learn this and struggling to get anything working at all
there are always missing libraries
Did you install Pimoroni's MicroPython firmware? The Official MicroPython firmware doesn't have Pimoroni's modules baked into it. If not, you can find it here (you want the .uf2 file).
(Not a Pimoroni staffer, just trying to help)
We've got a (hopefully!) beginner friendly tutorial for how to get started with MicroPython (and how to install our custom firmware) here: https://learn.pimoroni.com/tutorial/hel/getting-started-with-pico
Hey @UnfinishedStuff and @helgibbons
Yes - I used the custom firmware, and that worked fine for running just microphyton running fine, but it was when using the pimoroni periplerals - eg the RGB Keyboard where the examples didn't work so well
Thanks for getting back to me though :-)
Hey @UnfinishedStuff and @helgibbons
Yes - I used the custom firmware, and that worked fine for running just microphyton running fine, but it was when using the pimoroni periplerals - eg the RGB Keyboard where the examples didn't work so well
Thanks for getting back to me though :-)
I have a feeling the RGB_keypad will not get much more than it currently has which is a shame, but it is def being superseded by the keybow 2040. There is an adaptation of the keybow 2040 Lib that has helped me however, https://github.com/qbalsdon/pico_rgb_keypad_hid i do wish however the keybow 2040 lib could be used on the RGB_keypad as there is a lot more that could be done in there especially the layering effect.
I'm trying to help a friend and discovered the "custom" firmware. Why including libraries? The usual behavior is to have libraries added externally and keep the same MicroPython. Is there a reason I don't get? (which is perfectly possible)
Is there a reason I don't get?
We have to write C libraries one way or another to support Pico SDK, so it makes sense to bind them as Python libs rather than write yet another library for MicroPython. I realise this approach is a little against the grain and quickly falls apart (in some ways) if someone else does the same thing (or wants to use our breakouts with another MicroPython board). But it really was a tradeoff between this, or our sanity. At least for the time being!
I would like to say at this point that I personally thank you guys for all the hard work you do in creating and improving all the libraries! It’s the reason I only buy bits from yourselves and Adafruit. For me personally as I’m learning python it does make it harder as I don’t understand c very well but I do appreciate that supporting both in regards to the pico at this time must be a mammoth task!
Maybe, if you don't have the choice to keep them separate, you could emphasis that you have a specific custom MicroPython. The little link in the doc is here, but as it is an approach we don't see anywhere else, something more intense visually could help. It something that needs to be told to beginners that won't read that kind of thing in any tutorial. It really feels out of pythonic way of doing things.
I understand the hard work behind the scene and respect it, thanks.
Thanks for the encouraging words! And it's not just Pico- still have a whole history of product support nipping at my heels and a certain retro handheld to support. All good fun, though!
@titimoby totally agree regarding making knowledge of our custom .uf2 more obvious- I think we can link to the latest GitHub release so we should probably do that on all store pages with some accompanying text. C bindings, at least in the CPython world, are very Pythonic... one of Python's most compelling features, I think, unfortunately this doesn't translate well to MicroPython :laughing:
CC @helgibbons the link https://github.com/pimoroni/pimoroni-pico/releases/latest/
will always link to the latest GitHub release with our custom .uf2 attached. If you could direct people to this in the store pages I think that would help. I'll see about updating the README since it's confusing, not very useful and very neglected.
Separate MicroPython libraries are on my long-term wishlist, since I don't think our current approach is scalable for breakouts, but nearterm we just have to get something working. For things like displays we would ideally look at upstreaming more generic versions of our drivers into MicroPython itself and getting them included in the official RP .uf2 since they benefit significantly from being written in C. All big picture stuff, though :laughing:
Oh and to respond to @tempusfugit84 (sorry missed out there):
I have a feeling the RGB_keypad will not get much more than it currently has which is a shame,
We stuck with bare drivers for the RGB Keypad versus the whole custom keyboard solution that Sandy threw together for Keybow 2040 to differentiate the products somewhat. It's early days, but if the example you link is anything to go by then user examples of things to do with RGB Keypad (and everything else) will eventually far eclipse any effort we could muster. At least I hope it does!
That said- I think we do need more examples, and those will come with time.
When more examples do come it would be great if they could include more about how the wrapper but works as with the python libs you can dive in to see all the functions but I have no ideas how to do that when they are c. One of the reasons I picked the keypad over waiting for the keybow 2040 was that the pins were all available as I wanted to be able to use it to control relays and such to make a desk control hub controlling my lighting and such. More examples would def make this much easier to accomplish.