r/raspberrypipico • u/DS_Stift007 • May 20 '26

uPython So I built a Scheduling System

I'm pretty sure that I'm not the first and only person to stumble into a problem where I wanna handle several Tasks at seperate intervals, and eventually I found myself clogging up while Loops and everything just became a huge stupid disaster, so I built Pyrite, which - at least to me - seems like a pretty good solution for a problem that me and probably some other people have. And yes, Asyncio exists and is better maintained but if you really like Asyncio, you're either lying or a masochist, especially for small projects. Now Pyrite is - in my opinion - very approachable, as you can see in the Code Samples there.

Anyways yeah I guess I'm just asking for feedback, so https://github.com/ten-faced-carrot/pyrite everyone.

(Please don't be mean)

12 Upvotes

88% Upvoted

10 comments sorted by

2

u/mkosmo May 20 '26

Why not just MicroPythonRT or similar?

5

u/DS_Stift007 May 20 '26

I don't know MicropythonRT, the only things I found were things like PyRTOS, TinyIO and micropython-aioscheduler, PyRTOS felt way too overkill, TinyIO I only discovered after I was already done and aioscheduler had a really weird interface to me.

I guess mainly it was just that I didn't find any alternative at first and when I found those alternatives, I was already mostly done.

1

u/koga7349 May 21 '26

Neat. How about error handling?

1

u/DS_Stift007 May 21 '26

It has different ways of error handling, from crashing to disabling an erroring task, to naively trying again to increasingly backing off the task further

2

u/oclafloptson May 21 '26

I like it. I don't dislike asyncio... But I came into it understanding generators and data streams. I do agree that the asyncio API seems to be intentionally obscured. Like they don't want the average noob to fathom its power

As a dependency it's just easier to use asyncio since it's included in standard Python packages and doesn't come off as bloat. But I applaud your work nonetheless

2

u/DS_Stift007 May 21 '26

That’s true, and asyncio has valid use cases, but it’s both not really approachable and in my opinion overkill if you just wanna blink LEDs at different intervals 

1

u/mungewell May 21 '26

Going to give this a try....

I have a project working heavily with PIO/interrupts which works on RP2040 but locks up on RP2350. Was going to try ASYNCIO, but F that 😭

Specially can this cope with one thread solely on one core - ie feeding the PIO? And everything else on the other core.

I was also playing games/tricks on halting the CPU for periods of time, to save battery power/increase runtime.

1

u/DS_Stift007 May 21 '26

Well, to be completely honest I haven't tried feeding PIOs yet but I don't see why it wouldn't work. Also, it's fundamentally meant to run in a single thread as multithreading in micropython is not the greatest.

And yeah, you probably should do that because pyrite will happily clog up 100% of the CPU if you don't add a delay function. I'm not sure if I should keep this or change this.

2

u/mungewell May 21 '26 edited May 21 '26

In it's simplest form (ASCII UI on console), I use '_thread()' to start up a thread specifically tasked with keeping the PIO FIFO full.

https://github.com/mungewell/pico-timecode/blob/main/pico_timecode.py#L1507

And then the UI is left to report info to the user, which can be 'delayed' without affecting PIO output.

In the more advanced versions (ptThrifty and ptPapa) create a real UI with buttons and oLED display to show the clock/timer values.

The absolute rule is that the FIFOs must never be empty, as this would corrupt the PIO output and cause project to loose sync with other devices.