 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : PiGPIO for RPi5 now supported by SmallBasic (NOT MS-Small Basic)
| Author | Message | ||||
| PhenixRising Guru  Joined: 07/11/2023 Location: United KingdomPosts: 1453 |
Not an RPi user myself but I know that some of us are. Github link |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 690 |
Imagine MMBASIC running on a Raspberry Pi 5 with all its features and the power of the RaspberryPi 5 ... this would be insane  |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4067 |
"Just" needs someone willing to take over the Picromite code... (or to extend MMB4L). Whether the RPi 5 is the best CPU is debatable. John |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1453 |
For me, RPi 5, Android device, Windows, Linux would all be HMIs. Kinda attracted to MMB4W or MMB4A right now with PicoMites and ArmMite H7s handling the actual controlling. Odroid product is looking a bit good |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3396 |
Now, from the point of view of the C code for the long-ago PiCroMite ( https://www.thebackshed.com/forum/ViewTopic.php?FID=16&TID=13219 ), is this the same PiGPIO? Peter stopped supporting that because Raspberry Pi kept breaking his code by changing things under the hood. Would it compile (even if missing all the features added since 2020)? PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1453 |
For someone elsewhere, I just had to prove that my S-Curve acceleration routine did in fact work, by generating a plot. Look at any other solution out there because I haven't found one that isn't horrendously complicated   I know how to do this on the PC using SmallBASIC and so that's what I used. Basic just totally rocks, I don't care about this "non standard" talk because modifications are usually trivial. |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1453 |
The SmallBasic guys had a warning that their PiGPIO was only compatible with up to RPi-4 and they weren't sure whether they would get around to RPi-5 but apparently they have done. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4067 |
I expect it is (well a newer version). They do that with the Pico / SDK, too. It's often avoidable but people just break things anyway, sadly. With some effort, probably. I think we're short of a volunteer, though. John |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10371 |
PIGPIO hasn't been updated in 4 years. This doesn't use PIGPIO but Linux IOCTL calls. |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3396 |
I asked Google Gemini to "Compare Linux IOCTL calls and libgpiod". This gets to the core of modern GPIO interaction in Linux. Comparing raw ioctl calls and libgpiod is like comparing assembling a car from individual parts versus driving a fully manufactured car. Both achieve the goal of "transportation," but the experience, safety, and features are vastly different. In short, libgpiod is the modern, recommended, and vastly superior way for user-space applications to interact with GPIOs. The raw ioctl interface is the low-level kernel mechanism that libgpiod uses under the hood. Here is a detailed comparison:  Why would anyone use IOCTL now? PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2446 |
an old saying: the only problem that can not be solved by adding a[nother] layer of abstraction, is the problem of too many layers of abstraction each additional layer of abstraction (1) adds overall complexity, (2) consumes additional computing power, and (3) increases memory requirements. while it is certainly true that a carefully designed layer of abstraction may simplify the high-level programmer's job in some circumstances, in other circumstances it can do quite the opposite. where appropriate i use IOCTL calls myself, to good effect. in the case of the RPi the question is one of: how standardized are the I/O IOCTL calls vs how standardized are the PIGPIO calls? bearing in mind that, in theory, all I/O access goes via an interface with the binary "blob" - itself presenting a layer of abstraction. as Peter has noted variously in the past, PIGPIO for the RPi has presented him with a 'moving target' that continuously morphs to the extent of yielding an unmaintainable project. is IOCTL any better in the RPi case - who knows? cheers, rob :-) |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3396 |
In my experience as a programmer (since 1970), (1) is usually not true--abstraction behind the scenes (by others) simplifies the programs that I write, and Moore's law has made (2) and (3) fundamentally irrelevant in the vast majority of cases. In the particular case of Linux running on current devices (even tiny ones), it's not likely often to be the case that computing power or memory requirements constrain one to use IOCTL rather than libgpiod (when available). Concerning availability, the most up-to-date libgpiod is not available for installation on Raspberry pi using apt, but you can easily download and compile it. The next release of Raspbian (perhaps later this year) is expected to have the latest (later?) version of libgpiod, which is included in Debian 13 (officially released August 9). PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8015 |
And the later version will break what? If not that one then the next? The lowest level call to the hardware is always the most reliable, even if it's more complex. Then they change the hardware and it al goes round again as a new version is needed. Computers are nasty evil things that, as a programmer, you have to cajole, tempt and sometimes even bully into doing what you want. :) . Edited 2025-08-22 04:22 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2446 |
every layer of abstraction added, by definition, extends the 'path of execution' - ie, the CPU executes more instructions in order to achieve the same end result. execution of more instructions adds to the complexity; there is no free pass for code running "behind the scenes", it is still run irrespective of who wrote it. cheers, rob :-) |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3396 |
This is certainly true, but if the practical consequence for the user is undetectable, how does it matter? If a user presses a button on a screen to turn on a pin and it takes a millisecond longer if libgpiod has been used compared to IOCTL, it's not likely to make a difference. If it could make a difference, the non-deterministic timing of the Raspberry Pi would probably make it a poor choice for the application. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4067 |
Might be better to focus on why PIGPIO was useful / better than the alternatives (sysfs / libgpiod / ...) and what MMBasic needs (or needed for Picromite). There's also the issue of which libs to use and how stable their APIs are (if at all - it's as if this is nowadays forgotten [cf DLL hell]). John |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8015 |
Any abstraction layer is reliant on any layers beneath it remaining stable. The problem with the Raspberry Pi is that the hardware changes drastically and that's a binary blob - there is no access to it as it's the subject of a NDA. To keep up with any changes you have to be Raspberry Pi or change your mode of access immediately they make changes to their API. That's ok for an official Raspberry Pi developer but almost impossible for anyone else. IMHO the Raspberry Pi module is excellent for Raspberry Pi software and firmware but not much cop for anything else. The Pico is a far better platform in many ways as the hardware has been made more accessible. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4318 |
IMO this isn't a hardware or a software problem, it is a human problem, someone needs to have the time and inclination to do it AND the time and inclination to maintain it. The latter is more of a problem for a "real" computer than for a uC because by their very nature modern consumer computers are less-stable ecosystems. Not very helpful I know, but I was unable to refrain from commenting for any longer  .Best wishes, Tom Edited 2025-08-22 18:43 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10371 |
The point about PIGPIO was that it integrated access to all standard I/O functions on the Pi. libgpiod only deals with GPIO lines (digital input/output pins). ChatGPT: Taken together, this means developing and maintaining anything remotely like the PicoMite environment on a Linux platform is a massive undertaking. Unless and until Linux implements a complete I/O framework I think it is a non-starter. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
