Porting C based GPIO Programming from Raspian/Raspberry PI OS

Start Tutorials & Guides
, , ,
1

Is there a tutorial for taking C programs written to run on different RPi models and moving them to LePotato?

We have many thousands of PiDP-8 and PiDP-11s around the world [see https://obsolescence.wixsite.com/obsolescence/pidp-8 or https://obsolescence.wixsite.com/obsolescence/pidp-11] .

Oscar is about to release the PiDP-10 - BTW, and trying to get ahead of this we want to get the Simulator code: https://opensimh.org/ running on other systems, given the shortage of RPIs, i.e. we are looking at alternatives.

I purchased a LePotato since it meets the mechanical requirements and runs a version of Raspian (of sorts). That was why I bought one. But frankly, I am having mixed impressions. I have read as much of your documentation as I can find, explored this website, and done many internet searches.

I seem to find there are a lot of the traditional “See-Figure-One” style responses when people ask questions. This is a problematic attitude.

I’m a 50+ year UNIX kernel and original IP/TCP developer/implementor – I get it (and you are likely using some of my creations to read this message). LePotato is not an RPi, and you can not do everything. But you are failing the engineering rule of “least astonishment” – for instance telling some one to use /sys/class/dmi/id/board_* not /proc/cpuinfo needs to be made really clear in installation notes [or better yet - change the device trees to supply the same info fields that Raspian does so at least that code need not change].

However, you are selling it as an alternative. But if you want folks like this team to offer your board as same, a programmer like me needs to create an out-of-box experience that is a tad closer to what people get when they take an RPi of some flavor and install it in the kits. Many of these people are new to Linux, RPi et all. So the farther you are from what they expect, the harder it is for us to recommend using it.

If you are going to be close but not quite the same, programmers coming from Raspian needs at least an explanation, if not a tutorial on how to move C code from an RPI that used the GPIO pins for “charliepex-ed” lights and switches in our case, to your board.

Note: I have modified the board detection code so that is /proc/cpuinfo fails to return a “Model” line, to look in /sys/class/dmi/id/board_vendor and then /sys/class/dmi/id/board_name. We can use Linux’s libgpiod-dev to do the gpiod twiddling, but the names you are using are not quite the same - due to your lacking the device treemaps that Raspian supplies on boot. A simple tutorial that says first doe board recognition with … and then on what the Linux libgpiod-dev calls say: “GPIO5” [Line 5 on gpiochip0 on a RPi2], so the LePotato, call it will “7J1 Header PinX” … would be really helpful for folks trying to port code.

Thank you,
Clem Cole

2

The issue is that Raspberry Pi decided to modify the kernel to print out fields in various kernel virtual filesystems that are non-standard compared to upstream Linux. Then people start targeting these non-standard fields thinking these are standardized APIs when they’re just proprietary Raspberry Pi modifications.

These are standard fields used across the computer industry since the 1994, almost 30 years. Any Linux computer you boot will read these DMI fields from the BIOS and populate it. Again, this is industry standard and Raspberry Pi decided against using these standard interfaces to introduce their own so that they can lock in people targeting their software.

GPIOs chip and numbering are a function of the SoC used. These work with the Linux pinctrl system and the numbering is based on the physical hardware. We provide a quick lookup tool lgpio with documentation that can be found here: Libre Computer Wiring Tool
Again, libgpiod/pinctrl is a standard interface used across the Linux ecosystem by every vendor except Raspberry Pi.

We are not trying to be mean to our users. We are just stating fact of how things came to be this way. We try to move everyone to the correct API interfaces. If you have specific implementation questions, you can ask and we always answer. Asking us to port one of the poorly written Raspberry Pi GPIO libraries or hacky VFS interfaces is a no go.

1 Like
3

So your answer is “see figure one.” (Google the term please - if you don’t know it, it is a famous Computer Business reference from DEC VMS days - which I remember - I was there at the time that “SPR” response was written - “Mandatory defaults” indeed).

Your answer is not mean. It >>is<< short-sighted (although it is also your choice) FWIW: there is a term for what you are doing - in boat racing, it is called being a “Sea Lawyer.” Someone who is screaming that his boat has been fouled in a race while it’s sinking/is losing - they are unlikely to catch up. The smart racer understands you would rather not have to deal with it, but that is what you have to do to win the race.

Raspberry PI is an ecosystem. If you want to try to capture users from it (win the race), you need to provide at least a programming guide for >>C programmers<< come from the Raspberry PI and offer examples on moving from a programming standard → which Raspberry PI’s ecosystem has set, to what you provided - even if you think you are using “Linux” as your standard.

Simply, your wiring tool is insufficient for this task, and the people looking at this are pretty experienced (as I have said, I’ve been programming the UNIX kernel for over 50 years). It’s perfectly fair to say we used kernel.org’s recommendations for our interface but we also want to be a reasonable alternative to the RPi, so here is how to move to what we used, which, BTW follows KO’s recommendations.

If you did not want to be an alternative - why bother to invest in a flavor of Raspberry PI OS to run on the boards – just stick with pure Debian? Frankly, if you have not been mechanically and we thought SW compliant, we are unlikely to have considered your products as an alternative.

FWIW: I’ve employed more core Linux kernel developers than you folks have (google me), and I ran your answer by a few of them. None were impressed. In my over 50 years of systems development, I will tell you while this attitude works in the short run, it never lasts in the long run. But it is your choice. You can try to support programmers like us or not.

We have choices. We can continue to tell our users not to try to use Libre’s products like the LePotato. While it may work mechanically, it is not a sufficient replacement for the Raspberry PI boards from a SW standpoint. We are not going to lose any orders, as the RPi is a tool for us. We can also look at other alternatives, given the short supply. We also expect the shortage will solve itself at some point.

Also, another behavior observation from one of your customers. It seems to me from the few times I have tried to access you, folks, for more detailed information about your board so I could try to find a solution, your behavior of either not answering or basically saying, “see figure one” is showing that “Libre” is a name for you, and is really not a way of doing business. Freedom is about being transparent and easy to do business.

1 Like
4

Raspberry Pi is their own proprietary ecosystem. If we want to corner the market, we would do the same thing and not be “Libre” Computer. We only adhere to upstream standard created together with the open source community. We do everything with upstream. We funded a lot of the Allwinner, Amlogic, Rockchip, mesa, Linux media, and other work that is used even by our board competitors in Shenzhen.

Raspberry Pi is creating their own standard. We don’t like proprietary standards so we do foundational investments in open source infrastructure. We are not here to chase after Raspberry Pi as much as we are trying to supersede them by doing things correctly. You are entitled to your opinion and we are here to do what we set out to do. If not capturing some customers who are bound to Raspberry Pi’s ecosystem, then so be it. That’s not our purpose. Our goal is to create an upstream compliant ecosystem.

5

Which is saying once again “See figure one.”

Thank you for your replies. We have our answer and will walk away. I’ll try to return the board to the vendor as it has proven its worth to us.

Freedom means making it easy - which you are doing. That means making the documentation available (like the schematics - which are protected) and writing porting guides. Accepting that there are other standards - which you may not like - but make it easy for people to use them → the Principle of Least Astonishment. You can stick to your position, and that’s your choice.

6

We release full schematics for all of our products. Raspberry Pi does not.

We have already provided porting guides and tools on our GitHub.

Proprietary standards are not “libre”. Again, you fundamentally misunderstand what it means. Raspberry Pi does not release firmware or schematics. Numerous times they have locked out vendors trying to build compatible accessories in closed source firmware.

We are sticking to our position. We are pretty much the anti-thesis of what Raspberry Pi does in terms of creating an ecosystem. We only invest in upstream open source, nothing else. There are plenty of cheaper proprietary platforms but good luck getting them to work.

1 Like
7

Fundamentally we have already answered your question regarding GPIO in our initial reponse.

  1. Search for C GPIO and you will get this: C/C++ GPIO library

  2. Our original reply post pointed you to libretech-wiring-tool. You can use lgpio bcm PIGPIO# to get the GPIO chip/line based on the Raspberry Pi GPIO numbering or lgpio info HEADER PIN# to get it based on the header relative pin number.

In so far as we are concerned, we have provided all the tools and necessary information to port any application to the upstream gpiod interface.

8

1.) FYI: when I have tried to access your schematics - Google reports a protection violation and that I’m not allowed to access them. I asked for access [a few weeks ago actually] and have not received it.
2.) Your GitHub does offer some helpful hints. But it is insufficient to move code to your board, particularly if you want the code to run on both your board and on an RPi. That is my message to you – The tools. you just pointed to show how to build and boot a Raspian-like system. Your directory: Libre Computer Raspbian Portability does not supply what is needed. Simply a programming guide → if running on RPi, here is the pure Debian call to do that same that will work on our board.
3.) Telling people to use the gpiod library is fine – saying to use our mapping tool is not sufficient.
In your GitHub, please offer some source to a program that works both on the RPi and on your board, that uses all of the 40 PIN mappings and runs both using RPI’s scheme and yours. What would be even better is if your has an example of names that were identical. Simply: “2JY Header PinX” from gpioinfo is not the same as “GPIOx” when I run the tool on an RP2/3/4 – again “least astonishment” rules. So … if your defaults are different than you need to state in a tutorial: here are the specific steps to make them the same. Just like you do your boot tutorial. Simply: using lgpio bcm PIGPIO# to get the GPIO chip/line based on the Raspberry Pi GPIO numbering or lgpio info HEADER is “astonishing.” Explained in that manner makes it hard to write code that works on any PI style execution platform [which our simulations do – they check the board when they start, then fill in the blanks so the code that does the twiddling is independent of board/chip, etc]. I suspect we are not the only people that want to do that. Yes, I saw the BLINK program you offered[before I posed my first question BTW] - it’s trivial and not general, plus it does not run on both your board and an any “real” RPi.

I’ll not try to argue with you about what libre, open etc is. I suspect I have been doing this a tad longer and have more papers/credentials et al. than you do. You are wrong. I do “fundamentally” understand - what FOSS is about – I helped to create it (and have written about it). I’ll be honest it is clear you do not understand what we created for you … and it shows in your actions → “See figure one” is exactly what many of us years ago that started what is now called the FOSS movement (which I am one) were working against. But then and now, we can not change the fundamentals of human behavior. We can only offer suggestions and point out inconsistencies in how you are being understood with your action. If you do intend a different result, then you need to do a tad more and change your attitude. See figure one is different from “I understand, this is what we did, and this how its different from RPi. We know they did something different from KO, so we suggest you add code the works like this: …”

If you want to break Raspberry PI’s being “proprietary” in your eyes - they explain and/or offer the code examples on how to do it. Offering a solution is real Freedom, and that is just what we did [with UNIX originally in response to VMS et al in the 1970s]. And like UNIX even though it “Open Source” and anyone could license it and access it (which many did and the UNIX market place came about). But some firms (HP/IBM etc…) started to make UNIX private (just like RPi has). The answer for the market was Unix-workalike including *BSD and eventually Linux that were offered as FOSS platforms But most importantly offered tools (like GNU) to move code from the proprietary UNIX flavors → I helped create all that. You are riding that wave - which I think is wonderful.

I have no problem with your objections to what the RPi Foundation has done, but the way to “win” is to show a way out and help people with it.

That is what I’m encouraging you to do. But saying → it not XXX and those folks are bigger bullies than we are, is a tad childish. My experience is that, in the end, it is not very good business. And I have lived this a few times. I fought those wars too.

FWIW: I’m in the process of writing my report for the PiDP-8 and PiDP-11 mailing list that using your product to emulate in the “retro-computing” world as we have it is a likely dead end. It is a little sad, as a few of us has had hoped, as your words and descriptions sound excellent, but as I and others are finding in practice, it’s still a “See Figure One” world, and you are not really advancing it. Theory and Practice, once again, are not in alignment.

Yes, you folks get to stick to your position. It’s your product. But as customers, we can walk as we are not getting what we need. The RPi family works well for our use, and we can continue to do so. It would have been nice to offer your board as an alternative, but it is clear you don’t want to help us. As you said there are cheaper solutions yet and we are going to have to hack our code to make it work, maybe one of them might be a better target; particularly if we can get answers to our questions.

9

This is simply not the case. It’s both available on this hub and our website at www.libre.computer/ under Help → Schematics. There’s no authorization requirement. You can try an in an in-cognito window. We don’t know where you got your link but this is simply not the case.

Again, libgpiod is the STANDARD Linux interface. To say that a standard Linux interface lacks documentation or community is a bizarre statement to make as every developer on a non-Raspberry-Pi platform who touches GPIO uses this.

Please put this as a separate post requesting this feature.

This is a requirement by upstream Linux. We do not control this and we cannot merge any name we want into the upstream GPIO tree. These tools are all upstream tools of which there are standards for. Raspberry Pi’s GPIO numbering is arbitrary and match up to pretty much nothing. The header and GPIO numbers are completely different. There’s a fundamental difference between GPIO numbers and header numbers. These are two separate systems. Your statement indicates that you fundamentally do not understand how embedded systems works. It would help you to read some documentation since the conceptual model in your head is not how things work. This is not an attack on you so don’t interpret it as such.

We don’t support Pi style execution because it’s non-standard. Again, hate to sound like a broken record.

The reason is the hacked Raspberry Pi GPIO libraries are trash. If you continue to choose to use them, it’s your choice. libgpiod works on Raspberry Pi as well and it’s a simple struct with number lookups and conditional. We’re not going to support a non-standard API for GPIOs. Again, broken record.

You don’t know what we have done. We don’t know what you have done. This is off topic.

We follow FOSS industry standard interfaces. This is how the entire industry outside of Raspberry Pi does it. We don’t care for how Raspberry Pi does it.

The way out is to use standard interfaces that even Raspberry Pi support. We are not here to support old proprietary interfaces that even Raspberry Pi doesn’t support anymore. We are not here to port applications or build compatibility layers for old proprietary interfaces. Update your code to standards.

Again, update to standard interfaces. Old interfaces are deprecated even in Linux. Feel free to link to this thread.

You are entitled to your opinion. Others would disagree with you. We disagree with you. But thus is the way of the world.

We cannot get every customer or meet every customer request. It’s OK.

Our competitors offer ported trash libraries for some of their boards. This is our opinion but you are entitled to your own. We stick by our mission statement and opinion of what that statement means as we interpret it. We respect your opinion and extract whatever valuable criticism you offer.

10

1.) The subject of this topic is I was asking how to move gpio-based C code from Raspberry PI to your platform. Because you have not explained how to do it well, and it’s not easy to figure out what you have. So please do ask for another topic - that is the topic I started with – your response was “see figure one.” I will continue to note that what you have is not sufficient and you need at least a tutorial and example code showing how it works with RPI and how it works with you.

2.) Attacking me by saying I don’t understand embedded programming et al. actually made me chuckle. May I suggest instead of arguing with me (and your other customers - I’ve seen the similar – see figure one – in a number of the responses) I do ask you to think about what I’m saying and maybe, just maybe, consider that I might be trying to help you help me and others like me. The fact that the same basic question keeps reappearing in different ways, and you are telling people. we don’t do that, but actually, start to tell you maybe you want to consider doing something more than what you have now (see below for a story about that).

FWIW: I did look through the forum and found nothing useful to complete the task at hand (still don’t) before I asked my question last night. Yet, I’m hardly the first that suggests that what is there on the forum/in your GitHub WRT the gpio situation is incomplete - it may be a standard, but people coming from RPi will not know that.

What you have does not help convince me you want to really help people. BTW: I do a web search, I can find a lot of examples of how to GPIO programming for the RPi [even if it is their interface, not the “official” one from KO]. That same web search tells me little about Linux and Gpio - very few examples. Truth is, in the embedded world, I know people doing gpio programming in four ways → direct to the HW with the chip manufacturer’s doc, using a commercial RT OS product that targets that board, the Arduino family and its interface library, and then Raspberry PI’s. That does not mean Linux does not have a “standard” gpio interface. FWIW: for one of my former employer’s embedded devices which happened to be x86 of course, we built a user space Arduino library even though we had Linux kernel on the board – why? Because that was the code/applications we wanted to capture.

I’m not asking for that - I am asking for examples… for the RPi you did this, now do it like this. To be portable here a routine that will take a GPIO pin [using RPI numbering] return the proper parms for libgpiod-dev when running on your platform or an RPi – simple is good (again see below).

3.) The tool I am working with (SIMH/OpenSIMH) is older than Linux and was “FOSS” before Linus was in college (and available for free download → as source). It was written in C originally for VMS and UNIX and runs on a number of different platforms (including today, Windows, macOS, Linux, OVMS, etc…). A couple of us involved with those systems literally wrote a couple of the books and developed the languages (C/C++/Go/Rust) you and your generation are using for your product(s). We also have written/continue to be part of a number of the standards and including the POSIX, the LSB, stuff from KO, ISO C/C++/Fortran, etc… please don’t try to lecture on standards. You are standing on my and my peers’ shoulders here.

At one time, one of our European users, Oscar Vermeulen created a hardware 'Blinken-Lights" panel that originally looked like the PDP-8. He needed two things, a system to run simh and something to drive the LEDs and read the switches for his emulated front panel. Since the RPi was a Unix flavor (Linux) and supported the other - he picked it to drive the panel.

Since that time, he added a kit for a model PDP-11 front panel and is currently doing it again to use the OpenSIMH PDP-10 emulation with his new PDP-10 front panel. Along the way, Oscar’s “realcons” support, as it is called in OpenSIMH, has been moved from different models of RPi.

I am here today because a couple of us were musing about RPi availability and I started an investigation.

The point is that this work is not about Linux “standards” or anything other the possibly "replacing the RPi* → which you claim to be in the market. The topic on this list being we want a example of how to move C code that manipulated the GPIO subsystem - which currently runs fine on an RPi, to now run seamlessly on your platform (detecting the difference at run time).

Please try to remember that a carrot to people like me is much better – please offer path on how to do that. Don’t just denigrate the other platforms.

As a side, as I said above – in the early 1980s when we came out with UNIX on systems as an alternative to the proprietary Vax/VMS back in the day – the UNIX wars as they were called – what did we have to build besides the core UNIX systems → a VMS-compatible Fortran. Yet like you, we already had an ISO standard already (F77) - it was part of UNIX. But the customers’ code was written in VMS Fortran – it did not matter to them - if we wanted to capture them as a customer we needed to bridge the two systems. How do they easily get their code, with the least amount of rewrite from VMS to UNIX (BTW: we did such a good job, but years later DEC, and now Intel had to make their computers compliant with what we had done).

The lesson for you folks here – you can be right - what you have developed and offered on your boards is standard of sorts. It might even be “better” for some value than what it is replacing …but it does not help if that’s not what people have already coded too → in this case the realcons code was written in the moral equiv of VMS Fortran – RPI’s gpio interface code it needs to run both on RPi and anything we move it too.

I’ll also make a bold statement, particularly since what I have seen in questions on this forum, my group not alone here. We can and are likely to move on by the lack of help. But you might want to think about it the next time someone asks for technical help with a similar question about your gpio interface.

4.). I have googled you folks - it’s clear you have not done the same for me. Since you keep attacking me. I probably could be your grandfather and you are usiung stuff I created and have patents. I’ll even offer you a link to an invited paper that might help you understand the history a bit better that I wrote about 5 years ago for a French Journel looking at FOSS: La recherche sur les systèmes : des pivots dans l’histoire de l’informatique – II/II | HT2s | Cnam is the conference proper [site in in French/paper is English] that journal is: https://technique-societe.cnam.fr/medias/fichier/chc-7-8-2017-2-web_1523369142011-pdf My paper is on pages 111-128 Full disclosure, two of the authors, I often work with: Warren Toomey on things TUHS.org and was a review for Tom Haight’s wonderful book on the history of the computer business.

My point being you don’t have to like what I have to say, nor do anything with it of course. I offer it for free and as libre in the small hopes you might learn from someone that has been there and done that and some fairly important an influential people have come to and still do come too for advice.

BTW: It simply is still the case. I >>still<< get a protection error from Google Drive on my Mac 14.3/Chrome when I try to download the schematics – I can not tell you why only report the error – but that’s my experience. You can throw more insults instead of trying to figure out why it’s failing for some people if I am supposed to be able to see that file.

11

Can you personally post the URL you have tried to access? I just used Firefox, Chromium, Edge, and a fresh install on an SBC with no account information saved anywhere, and I can not reproduce anything other than loading the schematics. I have not owned an Apple device since the last one I could solder things to, so I can not determine if that is perhaps part of the issue. My only thought is perhaps you have a corporate Google account with special security requirements (seems unlikely) or that you have a VPN.

12

Thanks Tony [BTW: I did an apt install of chromium-browser on the LePotato and tried it there also - same as my Mac]

https://drive.google.com/file/d/0B1Rq7NcD_39QYnltdGtWWEFvS0U/view?usp=sharing which returns “access denied” = then ask to request access [which I did a few weeks ago].

Screenshot 2023-06-08 at 3.32.33 PM
Screenshot 2023-06-08 at 3.32.33 PM3248Ă—2010 706 KB

FYI, an Internet search points you to that page - well it returns a page in the forum from Sept 22, which tells you to try it.

I’m not behind a VPN or using a special account. Behind my internal network security, yes, and on 1G fiber, so performance should not be an issue. Networking setup is fairly traditional/professional, as one of the original Internet developers, ccc.com has been me since the beginning of Internet time.

I’m not sure it matters at this point. I have been given my answer (multiple times) → It’s our product, if you don’t like it, see figure one.

Frankly, with that attitude and insults from the forum person to my questions for a tutorial or real code examples on how to move C code from the RPi to their platform, I suspect we will look elsewhere.

That said, as I will report to the team, I’m not sure these folks get it - which, as an old guy that has been trying to birth the FOSS movement for over 50 years, it’s sad to see when we lose one - but like the UNIX wars you can only lead someone to the right answer. You get it or not → I’ve spent too much time down this rat hole. It’s not about making a statement that you are better and that someone else did something poorly/is not pure enough etc. You need to be open, free, and welcoming and try to encourage and help the users when they ask a question like this one - which is not what we found here

Perception is everything, and a reputation is lost so easily.

PiDP-x has a solution that works, using RPIs (with RPi Zero and 3 being the most often used). I’ll probably look at some of the other solutions, we were originally going to look at a different one when I found the LePotato and had hoped it might be an answer. If we do find one that we can suggest to users that is easy to get running and we can explain how to them, we will tell them how to do it in our instructions.

13

Interesting, I get a failure using your link as well, but it also doesn’t match any of the links provided by LC…

Ah hang on, it’s explained in the only place I can find that link:

image
image799Ă—225 13.1 KB

That post is saying the product page used to have the wrong link (then posted the bad link to demonstrate) The product page, and the page linked by LC early on both have the correct URL. That explains it.

These links are correct as provided by LC https://hub.libre.computer/t/board-hardware-schematics-links/36:

image
image826Ă—296 12.3 KB

14

We don’t control what others post online. Use official resources. They all work.

Simple Google search will give you tons of examples. We have already provided the tool to translate header+pin numbers to gpiod numbers as stated previously and repeatedly. You can plug those into any example code and it works.

Great for them. We don’t care about Raspberry Pi’s GPIO libraries at all as they makes ridiculous assumptions. It’s pure vendor lock-in and the reason you find yourself in your position today. You are asking us to steer into the same hole. If you actually take the time to see how we do things, you’ll realize our stuff is vendor agnostic, much better thought out and designed. Asking us to create a library that uses Raspberry Pi GPIO numbering is two steps back and one step forward. Better to drop it altogether and use header pin numbers as we have done. Instead of writing articles about how Raspberry Pi does things and how we should build compatibility layers, you should invest your time more wisely and realize that not adopting Raspberry Pi’s stuff is easier and cleaner as it avoids numerous non-portable assumptions. But to each their own.

We are here to answer questions pertaining to our platform. We’re not here to insult you. That would be pointless. Pointing you to the documentation you need repeatedly. You choosing to ignore them and asking us repeatedly for support of proprietary legacy interface that we indicated we will not provide. Use libgpiod, there’s tons of examples online and we provide the necessary lookup tools to make use of it quickly. Plenty of users already use the Python bindings without any issue. The C/C++ library is no different since Linus Wallejj, Bartosz Golaszewski, and others have spent extensive amounts of time validating everything.

We provided everything in an open, free, and welcoming format. This forum is dedicated to answering technical questions of which we have answered probably more than any vendor. There’s no point in telling us what FOSS means to you. Focus on technical questions as that is the purpose of this community. We have already answered your question but you don’t find our answer acceptable. We are at an impasse on this topic with contradictory opinions. That’s OK since as people, we don’t have to agree on everything.

You are at liberty to do what you please. The threat of using another platform if we don’t provide X is not going to make us provide it. We have told you that you need to do the transition to libgpiod. It is necessary on all other platforms as well since this is the standard. Other vendors don’t even bother providing lookup tools. If you think they are better for your application, then you are entitled to that opinion and free to use those platforms.

We cannot satisfy everyone. We have only answered your questions and you have rejected our answers. We have provided lookup tools and visual header maps to use the GPIOs across our entire board line by simply plugging in two numbers into a standard libgpiod example file. We will not port RaspiGPIO or any other Raspberry Pi official or user created library. We don’t really care for how Raspberry Pi does things even if they are a competitor in the space and market leader. This is an official position.

15

A little common sense from a relative newbie:

  1. FOSS applies to documentation as well as the software and hardware. You want a feature the devs don’t feel like making, and with half a century’s open-source experience you don’t know what to do? Give me a break. Nobody had the time or inclination make us a python blink example with libgpiod. So I figured it out for my self and made one. Try contributing rather than demanding.

  2. If you switch over to upstream methods your code will work on any board/Linux computer with minimal tweaking, so you don’t have to recommend or trash anyone’s hard work. By the way, going around threatening to heap derision on a product most folks here actually like in some newsletter nobody really cares about is just pissing in the wind–and boy isn’t your pant-leg wet?

  3. Your repetitive invocation of “Fig. 1” Is offensive and inaccurate. They gave you the answer you needed, and offered to answer any specific questions you came across in the future. So what is your problem? @librecomputer are not given to writing big omnibus tutorials, it just isn’t their style. It’s not like they’re telling you to “get bent” or whatever they said back in your day, they just pass on info in a different way than you’re used to. If you keep asking for something they already said no to, at some point they have to tell you to just deal with it. If that’s equivalent to flipping you the bird in your mind, then that’s something to talk to a therapist about.

As far as I’m concerned you came into our house and started acting like an entitled schmuck. To @librecomputer 's credit, they have been far more patient than I would have in dealing with you.

16

Lets not get into insults. There’s no point to insult each other. This is a technical forum.