matttrentini.bsky.social
129 posts
124 followers
78 following
Getting Started
Active Commenter
comment in response to
post
Is this what you're looking for @gadgetoid.com?
gist.github.com/andrewleech/...
comment in response to
post
[And, if the stars align, we may also have a demo of debugging MicroPython with VS Code!]
comment in response to
post
I know the author; this is a change he's wanted to make for a long time and he's well versed with Claude...
comment in response to
post
Why is it slow?
It can be if you're spending a lot of time in the interpreter but...don't do that. 😜
I use MicroPython commercially and it's rare that it's actually ever slow...
comment in response to
post
Yes, I feel your pain! It especially makes it hard to port CPython libs.
We've had a look at adding metaclass support (which would provide a way to implement enum) but...it's tricky. A lot of it is do-able but the devil was in the details.
comment in response to
post
That's mostly true, though you can embed MicroPython over the C API. Christian Walther has an example:
github.com/cwalther/pew...
But it'd be very nice to produce MicroPython bindings to all the C APIs...in this way you could write MicroPython on the Playdate - and it should perform very well.
comment in response to
post
I write MicroPython with VSCode - with just mpremote in a terminal.
There's no real need for an extension, though some folks do like them. mpremote does everything I need (and then some!).
comment in response to
post
Are they though? 😉
comment in response to
post
Maybe because VS Code traps some key presses by default?
There’s no issue with mpremote there, at least that I’m aware of!
comment in response to
post
Do you mean the WebREPL?
In any case, yes, mpremote is The Way. 😜
comment in response to
post
They're powerful little micros and I *really* want to play with them.
Unfortunately, the only available dev kit is for their E7 (much more powerful than the E3 used in the OpenMV AE3) which is a superset for their Ex family and can be configured to behave like an E3...but it costs ~$400. 😳
comment in response to
post
I haven't been able to get involved with this one - super busy with work at the moment - but have been watching it with interest!
Thanks for all your efforts trying to get it across the line! (and @rebelmike.bsky.social and @projectgus.aus.social.ap.brid.gy and Damien and everyone else!)
comment in response to
post
Don’t forget that Pin.board.LED_B is a thing too 😊
comment in response to
post
It would be nice to have a more complete MIDI library - but it's still quite new.
However, MicroPython has the huge benefit of being able to define the USB descriptors at runtime; a unique and killer feature! Makes it far easier to develop USB devices rather than having to compile/deploy.
comment in response to
post
We’ve used LVGL with MicroPython - and performance is identical to C. Which makes sense; you’re just calling through bindings to methods implemented in C.
LVGL is still tricky to build with, however; we’re working on that!
comment in response to
post
Sure...but it would be trivial to write that as a usermod or natmod and get the same perf from Python. Or use Viper or inline arm assembly - again, similar performance to C.
But yes, if perf is important, care needs to be taken with the implementation.
comment in response to
post
Actually, there are some Python methods there, haven’t checked if they’re used or not…
comment in response to
post
It’s using framebuf - although it’s Python it’s effectively forwarding functions to native code…
comment in response to
post
A few of us playing with your breakout code! 😜
Thanks again for sharing the repo in time so that we could get our hands on it during the meetup!
comment in response to
post
Interesting, have you taken a look what's going on on the wire?
The ESP32 has a slight theoretical edge (max 80MHz SPI rate) over the rp2350 (62ishMHz) but I'd have thought the display would be the bottleneck, as most have lower max transfer rates.
Anyway, I wonder what the source of the 20ms is?
comment in response to
post
I'm not sure if it's useful for you, but I created mpbuild - a python app - to help build MicroPython using containers for the toolchain dependencies:
github.com/mattytrentin...
comment in response to
post
Any chance that repo could pop up soonish? Sorry to be a pain but I host the Melbourne MicroPython Meetup - which is on Wednesday - and I'd love to show off your demo to the gang!
comment in response to
post
Here are the relevant USB HID libraries:
github.com/micropython/...
and here is aioble that you'll need to use to implement the HID protocol:
github.com/micropython/...
comment in response to
post
USBDevice has been in since v1.23:
github.com/micropython/...
And the higher-level HID, keyboard, mouse etc support has been in micropython-lib since around that release too:
github.com/micropython/...
It's really nice to use! USB descriptors can be defined at runtime. 😊
comment in response to
post
MicroPython should be able to? I've been meaning to do that for ages!
USB HID is definitely possible (it's really easy too!). BLE is possible too, and it should be neat with aioble. But the GATT definitions haven't been implemented so there's a bit of work to implement the HID protocol.
comment in response to
post
Had the same thought when I saw the pico-sdk release!
comment in response to
post
Gah, could have saved you a little bit of work!
github.com/mattytrentin...
comment in response to
post
Fuzzing has been discussed but it hasn't been investigated, to my knowledge. It would certainly be worth trying out!
Though I think what @gadgetoid.com was alluding to is the concept of fuzzing config compile-time parameters - that's not something I've heard anyone doing?
comment in response to
post
Yes, they do! I just personally have always been more interested in the encoders…
Your board looks very neat though!
comment in response to
post
If you’re enjoying building it, sure! 😊
But M5Stack make a *very* similar product which is quite affordable - and we have a MicroPython driver for it.
shop.m5stack.com/products/8-e...
comment in response to
post
This is so cool! Congrats on getting it working! 🤩
comment in response to
post
What are you doing that requires such performance?
I use MicroPython commercially and find it *much* easier to write C modules in the tiny chunks of code where higher perf is required. Which is rare.
comment in response to
post
MicroPython can do that too (except with the identical interpreter - and we also publish containers 😊) but there is no substitute for working on actual hardware. And, since mpremote makes it quick, there’s little cost to do so.
comment in response to
post
I've heard of folks creating MicroPython user modules with Rust but that's pretty immature.
However, you should check out Volodymyr's efforts to use Rust (and other langs) in *native* modules (runtime loadable) by compiling via wasm:
github.com/vshymanskyy/...
It's so crazy that this works! 😜
comment in response to
post
Yeah, I've just figured out that using MicroPython is always the best way! 😜 If I end up writing a C module as a worst-case fallback, well, that's no worse that starting in C in the first place! And it's never happened that I need to write *everything* in C for perf...
comment in response to
post
No, though I keep periodically trying. Still too many hallucinations and it doesn't suit my way of looking into things (open multiple tabs - with multiple perspectives - and rapidly sift through them).
comment in response to
post
mpremote also provides a better workflow, for me anyway. Particularly because you can use "mpremote mount" during development to work on your PC and mount (ie *not* copy!) the code to the device. Excellent for fast iterations.
comment in response to
post
I saw @rebelmike.bsky.social's patch...and was a little scared 😜
comment in response to
post
I like what you folks have done here, it's neat! But, perhaps next time, try reaching out to the MicroPython team first to develop a solution together?
We've already put effort into mip - which works for all devices - and I think we could have extended it a little to support your use cases.
comment in response to
post
We tend to guide people to use asyncio which is a better fit in most cases and much easier to use than threading. And well implemented in MicroPython.
I use asyncio in all of my 'serious' MP projects.
(Of course, if you need parallelism, you need threads, and will have to get a little dirty.)
comment in response to
post
Whether you define it as full or not is debatable - I'd only really make a case for it on rp2 (no GIL, second thread genuinely runs on the second core).
Threading is not wonderful in MicroPython, and it's still early days, but I haven't seen anything much better in Arduino either...
comment in response to
post
Multithreading is available on some ports (rp2, esp32, stm32) via the _thread library:
docs.micropython.org/en/latest/li...
However the implementation differs in important ways between those ports.