Finding out which GPIO is on which pin

On the Pi 1 Rev 1, pin 13 of the GPIO header is GPIO21, however, on the Pi 1 Rev 2, and subsequent later models of Pi, pin 13 changed to be GPIO27. Pins 3 & 5 also changed GPIO numbers. Is there a way I can programatically find out which GPIO is on pins 3,5 & 13? Is there something in the GPIO_Info SWI which tells me this? I assume there must be, but as usual I’m struggling to work it out. Any helpful suggestions welcome.

As a side note: Did you check the Tables file in the GPIO Module source?

https://gitlab.riscosopen.org/RiscOS/Sources/HWSupport/GPIO/-/blob/master/s/Tables

As for using GPIO_Info, in theory you could write a program that takes the output returned by GPIO_Info and then uses a copy of the tables in the file above to resolve the internal pin with the actual pin, but it would probably be better to add a new SWI, something like GPIO_GetPhysicalPinMapping in the GPIO Module.

HTH

It would be better to have an abstraction that would support any kind of GPIO hardware, such as any number of this kind of USB device:

It would be better to have an abstraction that would support any kind of GPIO hardware

Indeed. I think that was the idea with the GPIO Module, probably never got completed though.

Last night I had a look at the full source and wrote the entire documentation of what I think it’s trying to do. So, the AI now it’s fully aware of it and I also wrote a couple of mapping tables for the Pi and the BeagleBoard, but it needs testing. However the module is now fully documentated.

As for the approach itself used to write the module, it seems (at least to me) that ROOL attempted to write the abstraction in stages, this might be the reason behind the tables organised as they are.

What I don’t understand thought is why using ASM? This is a perfect candidate to be written in C (with ASM portions in case one is abnoxious about latency…). Maybe I am just being too picky though.

I thought the Rev 1 had 256MB of memory and the Rev 2 had been expanded to 512MB. A simple memory check might have sufficed.

However, after a little research, Rev 2 was released on 5th September 2012, also with 256MB.

This was expanded to 512MB on 15th October 2012.

Info from reading old RaspberryPi.com news articles.

So no help there.

I could use OS_ReadSysInfo 9 to get the version of the board in use and use that to determine which pins are what, but that SYS call is specifically documented as “…not to be used to programmatically infer hardware or OS capabilities.”. In fact we’ve been repeatedly told we shouldn’t be looking at what board the code is running on, but should check for required features instead. Therefore, I assume there is a correct way to find out what GPIO is on what pin, which shouldn’t require reading the board name or somehow making reference to a source tree every time the code is run, but I’m just not finding it.

It would be better to have an abstraction that would support any kind of GPIO hardware, such as any number of this kind of USB device

The (user facing) API can certainly encompass a breakout board like that. It already supports an arbitrary number of controllers up to 32b per port. At present the low level (not user facing) API is one that hunts for a HAL GPIO device, but there’s no particular reason why it couldn’t accept USB devices added at runtime, just nobody’s had a use case or motivation to do so.

What I don’t understand thought is why using ASM? This is a perfect candidate to be written in C (with ASM portions in case one is abnoxious about latency…). Maybe I am just being too picky though.

You’re looking at the wrong sources, the GPIO module is definitely written in C.

we’ve been repeatedly told we shouldn’t be looking at what board the code is running on

That is perfectly valid. Unfortunately it falls at the first hurdle and, while an end-user program should not be enquiring what the hardware is and adapting accordingly, arguably the GPIO system should be doing this, but I don’t think it does (as far as I can see).

Which leaves one in a state of having to do dumb things like “is the BCMVideo module present? is there only 256MB on board? Then maybe it’s a revision 1 Pi…” because the OS, that knows, isn’t going to share what it knows because somebody somewhere might use that information.

Far better, in my useless opinion, to have a call (like the OS_Hardware used to) that returned board type and revision along with a stern warning that this information should not be used unless there is an actual specific need (as in this case). For 99.9% of the time, there’s no need to know this sort of thing. But then, sometimes there just is…

Thanks Sprow

I stand corrected! The looking at the wrong code was triggered by the Git Lab UI always going to `master` branch when using the `open link in a new tab` plus me looking at this at around 3am in the morning XD.

The master branch still has the Assembly version…

tonight I’ll redo my documentation using the C version in the branch you pointed me at, thanks.

The HAL does detect which board it’s running on and returns a string (as mentioned earlier), which is how I determined which layout to use for !GPIOConfig. This is also used by the GPIO code in the HAL to determine what set of pins are available to be used by the GPIO module.
Running GPIOConfig will present a window with the layout of the board and which pins are where. Also this BASIC prog will list the pins and their ALT uses.

Far better, in my useless opinion, to have a call (like the OS_Hardware used to) that returned board type and revision along with a stern warning that this information should not be used unless there is an actual specific need (as in this case). For 99.9% of the time, there’s no need to know this sort of thing. But then, sometimes there just is…

OS_ReadSysInfo does just this, but comes with a stern warning that “the main purpose of this call is to provide information for debug/logging purposes. It is not to be used to programmatically infer hardware or OS capabilities.” with no get-out of “unless you need to”.

The HAL does detect which board it’s running on and returns a string (as mentioned earlier), which is how I determined which layout to use for !GPIOConfig. This is also used by the GPIO code in the HAL to determine what set of pins are available to be used by the GPIO module.

Yes, the GPIO module needs to know which board it is on, to know which GPIOs are available to talk to. If it could expose GPIO→pin mappings to the programmer so they can make use of the information, it would be more useful. I’m still trying to find out how to officially and properly do this.

As for using GPIO_Info, in theory you could write a program that takes the output returned by GPIO_Info and then uses a copy of the tables in the file above to resolve the internal pin with the actual pin, but it would probably be better to add a new SWI, something like GPIO_GetPhysicalPinMapping in the GPIO Module.

Come again? More sleep (or coffee) needed I think. Why not just use the existing GPIO_Info SWI to ask for the information you want? No grubbing around in HAL sources, no OS_ReadSysInfo dubious string matching.

Rephrasing the OP’s question what I think is being asked is: “Can I use GPIO 0, 1, 21 or have they vanished and I must use GPIO 2, 3, 27 instead?”. So go right ahead and enumerate the pins:

key%=0:desc%=0
REPEAT
  SYS"GPIO_Info",&4c4c5546,key%,desc% TOpin%,key%,desc%,log%:REM &4c4c5546 is 'FULL'
  PRINTlog%,~pin%!4,~pin%!8,~pin%!12,~pin%!16
UNTILkey%=-1

When run on a Pi 1 rev 1 the enumerated list does include 0/1/21, or conversely on the later Pi models the list doesn’t include 0/1/21 (or if you’re a glass half full person it does include 2/3/27).

Come again? More sleep (or coffee) needed I think.

Indeed… I mean the master branch still having the old code in ASM and the gitlab UI always defaulting on the master branch clearly is a sign someone is handling things in a funny way (regardless the old CSV ways) ;) – Maybe some sleep and more coffee could help?

Why not just use the existing GPIO_Info SWI to ask for the information you want? No grubbing around in HAL sources, no OS_ReadSysInfo dubious string matching.

Indeed, I have never mentioned the HAL, nor memory amount chechings and exotic things like that (I guess here you were answering someone else’s point instead?). So sure more coffee sounds like the way to go ;)

As for the other’s comments, Sprow is correct, both the old code and the new GPIO do check for the machine and when a user calls GPIO_Info (the old ASM code) loads the machine table in the RMA and use that to return response to the user (there are a couple of subroutines used for this in the SupportCode file)… again for the old ASM version which still lives in the master branch because RISC OS :)

So, just using GPIO_Info is fine for Andrew’s problem, thought it’s not intuitive if someone is not looking at the sources (hence my suggestion), and, looking at the Wiki I think Andrew is the one trying to document all this?

HTH

When run on a Pi 1 the enumerated list does include 0/1/21

That’s incorrect – when run on a Pi1 PCB 1.0 the list includes 0/1/21 (but not 2/3/27), when run on a Pi 1 PCB 2.0 the list does not include 0/1/21 (but does include 2/3/27)

on the later Pi models the list doesn’t include 0/1/21 (or if you’re a glass half full person it does include 2/3/27).

That’s incorrect, all Pi models except the Pi 1 PCB 2.0 appear to include GPIOs 0/1/21 in the enumerated list.

So, to determine which wiring you have, you have to count total number of GPIOs, and then if you have 17 it’s a Pi 1, if you have 28 it’s a later Pi (from B+ up to 4B) which, so far, all have the same GPIOs on the same pins. If it’s a Pi 1 then you need to check for GPIOs 0/1/21. If 0/1/21 are present it’s a Pi 1 PCB 1.0, if 2/3/27 are present, it’s a Pi 1 PCB 2.0.

So, just using GPIO_Info is fine for Andrew’s problem, thought it’s not intuitive if someone is not looking at the sources

That’s fine, as has been pointed out numerous times over the years, I’m generally just too stupid to understand the documentation.

Not to mention… String parsing? Really? As if that can’t go wrong. ¹

There used to be an API call that would return two numbers. One was the board type, the other the revision. Much simpler to deal with.

¹ Why do you think Microsoft went from Windows 8 to Windows 10?

@ Andrew

That’s fine, as has been pointed out numerous times over the years, I’m generally just too stupid to understand the documentation.

I’d be careful about spending time with people who make you feel “too stupid” for not being able to read a programming language. It’s like saying someone is “too stupid” to understand French or Italian just because they only speak English! Language familiarity doesn’t measure intelligence!

To me, it doesn’t sound like you’re hanging out with the smartest folks, my friend. 😉

Not to mention…

Indeed AND the best part: If the code mistakes to understand the machine, the whole table used by GPIO_Info is wrong. Another reason why I have suggested to have a SWI we can query (regardless the current machine) to get the mapping.

It sounds to me that on the test case Andrew has reported this is what it may be happening, but in all honesty I had no time yet to sit and look at the C version in details, so not sure yet of what is happening.

To me, it doesn’t sound like you’re hanging out with the smartest folks,

Hmmm, “the smartest folks”…

Depends on what you want people to be smart at really.
I know KC’s, nuclear scientists, power grid techs, professors, lorry drivers and more,¹ and smart in one field and dense in common sense is a common situation.
The nuclear techs can be extraordinarily daft at times.

¹ CAMRA really does seem to have members representing all professions. Our GBBF ‘staffing’ officer did say she was pretty sure that “even the oldest was represented”.

smart in one field and dense in common sense is a common situation.

I used to say at work that the degree of common sense is in inverse proportion to the number of degrees held.

For example when one of our PHD gentlemen was cleaning out the bell jar after evaporating a metal coating onto something (this was a routine operation) but couldn’t find an airline to blow it out, he used a hydrogen cylinder instead. As he was using a vacuum cleaner to catch the bits, there was a somewhat muffled bang as the dust bag of the vac inverted. The cleanup took some time. The laughter took longer to die down.

I used to say at work that the degree of common sense is in inverse proportion to the number of degrees held.

There’s always an exception, isn’t there?
One of my father’s work colleagues: David Newman or Dr. David Newman (or more accurately multiple-Dr. Newman) great guy, dressed in jeans and tee most of the time, acted like a post-grad student¹, thoroughly nice and sensible guy.

¹ I thought he was, until he walked with schoolboy me to the secretaries room, asked to have my notes on the new E-PROM programmer typed up (for students to learn from) and they responded with “how many copies Doctor Newman?”)

I used to say at work that the degree of common sense is in inverse proportion to the number of degrees held.

I’m not sure I’d say anything about common sense given what just happened on the other side of the ocean.

That being said, I think that there may be a problem that somebody who is highly specialised in something is unable to apply general knowledge to general things. Perhaps they overthink it?
Example? Mom knew a guy many years ago when I was young. Doctor of some obscure maths topic. Like if you want to know how to draw a logo to print onto a balloon so that it looked correct when the balloon is inflated, he was your guy. And he could do this stuff in his head, easily demonstrated by giving him a logo design (like, say, the Renault logo) which he’d draw with magic marker and, yeah, when inflated it would be correct and not bendy or deformed.

Mom used to help him organise his expenses as simple maths was completely beyond him. Ask him to add up the items in his shopping basket and he’d be lost. Didn’t even do what I do and “round to nearest” for an approximate amount. And that was back in the days when things had sticky price tags attached, before all this barcode stuff.

He wasn’t stupid, far from it. But I think his brain was so specialised in what he did (and got paid for) that all the simpler stuff just faded away.

The nuclear techs People can be extraordinarily daft at times.

Fixed that for you. You’re welcome.

Oh, and just being a boffin doesn’t make you immune you arse-up moments. It just means that more people notice because they think that knowing how to launch a rocket means you know how to wire a plug, etc etc.

there was a somewhat muffled bang

Hydrogen and electric motors. He’s lucky that a muffled bang was all it was.

That’s incorrect – when run on a Pi1 PCB 1.0 the list includes 0/1/21 (but not 2/3/27), when run on a Pi 1 PCB 2.0 the list does not include 0/1/21 (but does include 2/3/27)

What is also notable is that on the Pi1 PCB 2.0 GPIOs 28-31 are not enumerated at all, and so can not be controlled from RISC OS. I seem to remember that the original version of the GPIO module, written by Tank, enumerated them properly and so you could control those 4 GPIOs also.

When run on a Pi 1 the enumerated list does include 0/1/21

That’s incorrect – when run on a Pi1 PCB 1.0 the list includes 0/1/21 (but not 2/3/27)

My sloppy wording, by “later Pi models” I meant Pi 2 onwards. I’ve edited the post to be specific about Pi 1 rev 1.

What is also notable is that on the Pi1 PCB 2.0 GPIOs 28-31 are not enumerated at all, and so can not be controlled from RISC OS.

That looks like a mistake in the tables, you must be the only person in the Venn diagram of using a Pi 1 rev 2 and using RISC OS and having soldered something into the holes for P5. I’ve proposed a fix marking those as usable.

Why not just use the existing GPIO_Info SWI to ask for the information you want? No grubbing around in HAL sources, no OS_ReadSysInfo dubious string matching.

Indeed, I have never mentioned the HAL, nor memory amount chechings and exotic things like that (I guess here you were answering someone else’s point instead?).

I got confused which tables you were recommending looking at. I thought it was the table in the HAL (wrong: don’t do that, use the user facing API) when it was actually the table in the abandoned assembler sources (wrong: don’t use those, use the user facing API). Sorry about that, it’s difficult to hook out the useful content in this thread mixed in with the unrelated chatter.