Comment by numpad0
19 days ago
Why do everyone latch onto bit-banging pins from Linux??? Isn't that going to exhibit wildly unpredictable delays? Wouldn't you normally compartmentalize hardware handling into an OS-free or hard-realtime microcontroller and let the uC communicate with host CPU in less-realtime manners?
You can roll your own "RGB temperature sensing modem" and get/set values with `bash` and `expect` over ttyUSB, no one PWM controls RGB LEDs on a gaming keyboard straight from a task tray app. Trying to wrestle GPIO problems that way is going to be unnecessarily hard.
Not sure which part you're referring to, but I agree. The u2if firmware I'm using has an interface type that generates the addressable LED bitstream with the RP2040's PIOs. The host software dumps the pixel color values over USB CDC into a buffer on the RP2040, then when it's done the firmware tells the PIO to read the buffer with DMA and stream out the precisely timed LED bitstream.
Currently it's running in "one light string per PIO" mode but there's an inaccessible mode where one PIO can do up to 8 strings simultaneously. The pins have to be physically adjacent, though, so it's a bit more difficult to set up in a generalized way.
> an inaccessible mode where one PIO can do
Clarification please. I thought inaccessible meant cannot do :)
Well, sure :) It's a function present in the PIO code that isn't called by the current firmware setup.
1 reply →
Ah, yeah, that’s the right way to do it, but if you can get away with using a Pi you don’t have to write a second program for your Arduino, haha. People who are happy to do it the right way were already well served, right?