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.