I had this idea while writing the a PIO driver for the touch. If you don’t wire the touch interrupt pin, you could do just store threshold in one of the SM scratch registers and then trigger dma /interrupt if the value changes . But you’ll need 1 SM for each axis but this works fine

Hell yeah brother! I just refactored obj2c to load files dynamically. The ui spins up a render process which opens a socket and waits for the orientation.olive renders the pixels into a socket and I read that into tkinter canvas .All self contained with nob. Absolute tsoding 😂

I cheated a bit with the 3d render. Had to go back to C. Sorry but there are no sane libraries in python to do headless rendering. I even tried Godot but it doesn’t render in headless mode. I ended up using @tsoding.bsky.social Olive.c cos I thought it was funny. Gonna replace it with raylib soon

Kettles , teapots and whatnots . You know the saying

Hmm, async/await has been very elegant in MicroPython on microcontrollers - simple to write, easy to reason with. Threads, in any form, are not particularly well supported in that domain.

I concede that embedded Python is a small niche 😜

I 💯 agree , in fact it spurred me to create my blog I started writing a response but I’ve not had time to finish it. Turns out I have a whole lot of opinions after reading posts and watching talks, there are lots of points to respond to. Glad this popped up again. I’m gonna try and finish it asap.

You’re looking for multiprocessing. Threads are for preemptive multitasking and coroutines for cooperative multitasking.

I use the pcf8574 for the toggle switches as well, the joysticks used to use thd pcf8591

bsky.app/profile/immo...

I see, I think you’ll need digital io expanders like the pcf8574. Since buttons are either pressed or released, you don’t need analog pins for those . In my current project , I use the pcf8574 to read button and toggle switch states . The buttons emit single press, double press or long press events

Awesome! I'd recommend the pcf8591 if you dont need the resolution. It's faster and less noisy than the ads1115. and if i remember correctly you can read all channels at once, with the ads1115 you have to sample each channel sequentially. There are faster alternatives if you go the ads route

Hi 👋, you should look into analog multiplexers like the 74HC4067. I think that might solve your analog channel problem . I’ve not tried that particular chip but I’ve used others like the CD4066BE . If you prefer external adcs you could look at the pcf8591 or ads1115 etc.

2/2.. applications in constrained environments . It’s also super neat writing once and running on full phat desktop python and micropython with no changes.
I’ve only had to patch a couple of simple methods like sleep . Just created a blog so to share the lessons I learned, so stay tuned 👍🏾

Okay upon further reading I think I understand your push a bit more. This is to decouple the os threads from pythons threads on the for the entire language, hence the virtual part. Got it . I see how that benefits existing blocking code without having to spin up more interpreters and processes

Aah, I see the issue but I think the root cause is that most of these packages were designed before the async /await paradigm. I don’t think we should be making the old stuff fit. I think that’s the appeal of FastApi. I’ve given up on moving my Django apps to full async. More apis won’t fix that

2/2 I do something similar on multicore microcontrollers usually with no Gil . I have an app that runs on the other core and accepts tasks to process they can be long running using generators or just a single call .The api interfaces with that in either sync/ async. You can spawn more threads on pc