Automation, sensing and robotics • Re: Pleb GPIO

Warthog, thank you for taking a look! I figured you would, if anybody did. I did spot leds-gpio but could not make sense out of it.

And some people have trouble learning to drive. But that isn't sufficient reason to re-invent the wheel. Or to buy a Tesla.

You should definitely consider that to be my failing -- but suspect others may have it too. You are a complete insider with great technical skills and an intimate knowledge of this area. It may undermine your ability to see what new developers see. Also, without a normal man page and fulsome documentation, it didn't feel reliable. I am freshly burnt on sudden deprecations here.

I'm not a "complete insider". Not even sure what that is. I just saw a problem that needed fixing and happened to have the skill set required to have a go at fixing it.
I was also looking to give something back after finding open source beneficial - and that seemed a good fit.

I'm really tired of this "sudden deprecations" BS. On the kernel side things are deprecated for years before they get removed. The problem is downstream users who either don't pay attention or don't want to move from what is already working for them. e.g. the GPIO sysfs interface was deprecated in 2016. Yet how many libraries etc still use it? And now people complain when it finally starts getting removed - despite the original deprecation warning that it would be removed in 2020. How much time do people need??

The Pi5 non-backwardly compatible debacle is whole other story, and outside my scope. That certainly could've been handled better. I suspect the impending IPO made them rush it, though that is purely speculation.

I'm also tired of the "oh but it doesn't have a man-page so it isn't reliable" argument. That is BS. There is loads of stuff you use every day that doesn't have a man page or otherwise lacks documentation, but that doesn't stop you using it. And in this case we are talking about a kernel ABI. The kernel goes out of its way not to break ABI. If there is a problem with an ABI it gets deprecated, replaced with something better, and eventually removed. e.g. the original version of the GPIO uAPI is still there. That process takes years and is public, as is the whole kernel development process. There are no "sudden deprecations" that break kernel interfaces - though it might look that way if you are asleep at the wheel.

Hey, between you and me, here is why I posted this: Open software been vewy vewy good to me. When I see a reasonable opportunity to give back, I (sometimes) try. Having read several Pi forum threads with people spinning in circles and pulling their hair about gpio libraries, it seemed like this might be a place to add value. But I have no ego tied to it; Pleb-GPIO can sink without a ripple for all I care. The repo is on github andI have made the offer here.

You are familiar with the xkcd standards joke?

See above wrt broken libraries. Any library authors using GPIO sysfs were using a deprecated interface. That is on them. I've got such a library myself - and it has had a warning on it for years that it relies on GPIO sysfs and that will eventually be removed and things will break.

Any library authors using direct memory access to the peripheral registers were also playing with fire. So getting burnt is to be expected. They didn't tell you that? And if they didn't even realise then you probably shouldn't be using their library.

Rather than re-inventing the wheel again, you could've spent time sorting out how the LED sysfs interface works, and device tree and dtoverlay, and either documenting it better for others or providing a wrapper library for it, and filling any gaps you might find by providing kernel patches.

Hey, about interrupts. We do a Pi4-based system that does real-time audio multicasting for up to 50 clients, including WAV to MP3 conversion. We optimize the stuff that matters and not the stuff that doesn't matter. Pleb-GPIO consistently takes 0.3% of one CPU. In other words, I could not come up with an experiment where I could show it to cause any degradation -- it's below the noise level.

You use little CPU as you use slow polling. That will completely miss short button presses. Interrupts wont. And they use less CPU. And it requires less code.
Polling might be fine for you, but it can be done better, so why not do it better?

Statistics: Posted by warthog618 — Mon Oct 07, 2024 1:53 am

---