GPIO confusion


23 posts
by jetlag » Wed Jun 06, 2012 9:52 am
Can someone please help to clear up the utter confusion surrounding the GPIO and the expansion header.

In this months MagPi there is an article that uses a switch as an input device, connected to GPIO 11,
and expansion header pin 11.
In the Python program;

GPIO.setup(11. GPIO.in) & mybutton = GPIO.input(11)

If we now look at the Rpi Wiki, this shows pin 11 on the expansion header as GPIO 17

Which is correct ?

cheers
jetlag
Posts: 5
Joined: Wed Jun 06, 2012 9:47 am
by texy » Wed Jun 06, 2012 12:16 pm
Hi,
there are 2 methods of labeling the I/O lines - those from on the Pi connector, GPIO-11 in this case, and the other from the BCM chip itself, which
is 17 in this case. Yes, its confusing, but the RPi.GPIO python package allows for both version to be used, by using the command
Code: Select all
GPIO.setmode(GPIO.BCM)


...it defaults to the Pi pin numbering otherwise.
See http://pypi.python.org/pypi/RPi.GPIO

Regards
Texy
"2.8inch TFT LCD + Touch screen" add-on boards for sale here :
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=93&t=65566
50p goes to the Foundation ;-)
Moderator
Posts: 2202
Joined: Sat Mar 03, 2012 10:59 am
Location: Berkshire, England
by jetlag » Wed Jun 06, 2012 2:08 pm
Texy,
many thanks, that's made it clear as crystal.

cheers
jetlag
Posts: 5
Joined: Wed Jun 06, 2012 9:47 am
by Grumpy Mike » Sat Jun 09, 2012 5:43 pm
texy wrote:Hi,
there are 2 methods of labeling the I/O lines - those from on the Pi connector, GPIO-11 in this case, and the other from the BCM chip itself,

So you use the pin number on the header. This is a total nonsense and is a recipe for long term confusion. Sadly this appears to be what the people organising Python have opted for. It is the work of the devil. The correct name to use is the name of the signal coming out of the chip, because at the end of the day you have to have code that addresses the correct pin, hiding it is just unnecessary obfuscation.
User avatar
Posts: 748
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
by sharpapotheosis » Sat Jun 09, 2012 6:51 pm
Sadly this appears to be what the people organising Python have opted for.

It's nothing to do with the people "organising python", more to do with the people who wrote this specific library.

. The correct name to use is the name of the signal coming out of the chip, because at the end of the day you have to have code that addresses the correct pin, hiding it is just unnecessary obfuscation.

Absolutely not. For the average person who is only using python to interface with their IO systems, it makes perfect sense. It's an abstraction layer: they don't need to know which pin is GPIO17 (and if you've noticed those numbers are not in a logical order), instead they can count the physical pins, connect their jumper wire and get going.

When you assign a variable in python, you don't tell it which memory address to put it in. In fact you don't even know for the most part: you just assign the variable. In the same way, these libraries are here to remove the necessity for the knowledge of things like addresses: that's what the library does for you. However, as a bonus they've included the ability to use the GPIOx number system, so what's the problem?
Posts: 58
Joined: Thu May 24, 2012 6:47 pm
by Grumpy Mike » Sat Jun 09, 2012 9:21 pm
sharpapotheosis wrote:
Absolutely not. For the average person who is only using python to interface with their IO systems, it makes perfect sense. It's an abstraction layer: they don't need to know which pin is GPIO17 (and if you've noticed those numbers are not in a logical order), instead they can count the physical pins, connect their jumper wire and get going.

Absolutely is. I get fed up of the dumming down excuse by evoking a theoretical average person. I think this is very condescending of you. You can understand it but the average person might not, this is tosh. So what is your excuse to them in counting physical pins and saying "no that is not a GPIO it is a 3V3 line or a ground or a don't connect"? That is even more illogical by your warped sense of what is logic.

(and if you've noticed those numbers are not in a logical order),

So what is a logical order? You just underline your lack of understanding with a phrase like this.
The pins are in the order they are, and they use the GPIO numbers they do because:-
1) Some of the alternative uses have been used in the design of the Pi like the SD card and Ethernet
2) You can't track out all the pins on a BGA chip on such a low cost board.
3) The PCB designer has many other concerns than prissy expectations of what is and what is not logical.
User avatar
Posts: 748
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
by sharpapotheosis » Sun Jun 10, 2012 1:46 pm
Absolutely is. I get fed up of the dumming down excuse by evoking a theoretical average person. I think this is very condescending of you. You can understand it but the average person might not, this is tosh. So what is your excuse to them in counting physical pins and saying "no that is not a GPIO it is a 3V3 line or a ground or a don't connect"?

I would include myself in this group of "average people". I don't need to know about the GPIO numbers. I connect my wires by counting the pins, looking on the diagram to check whether it is a usable pin or not, rather than looking at the diagram, counting the pin number, scrolling down the page and finding that pin number, and then using that GPIO number.


So what is a logical order?

One that goes up from 1 to 26.

The pins are in the order they are, and they use the GPIO numbers they do because:-
1) Some of the alternative uses have been used in the design of the Pi like the SD card and Ethernet
2) You can't track out all the pins on a BGA chip on such a low cost board.
3) The PCB designer has many other concerns than prissy expectations of what is and what is not logical.

I understand this. There are perfectly good reasons for assigning the pins as they are. I'm not denying that. But while the PCB designer doesn't worry about the concerns of what's logical, the fantastic job of software designers is that they can.

But this is missing the point. My point is that OK, the pins have GPIO numbers according to addresses in memory somewhere, but the software provides a layer of abstraction that will remove some obfuscation for some people. Better than that, it has been designed as an optional layer of abstraction, so if you don't like it, remove it. If you really care about the addresses and the likes, write your program in C.

Given that, I don't see what you're complaining about: the feature that you want exists - and is easily usable - and the simple 1,2,3,4 way of numbering pins has been implemented for those for whom addresses and PCB design are knowledge they don't have, let's say children (the very people the Pi was created for). So what is your problem?
Posts: 58
Joined: Thu May 24, 2012 6:47 pm
by jecxjo » Sun Jun 10, 2012 2:12 pm
sharpapotheosis wrote:
Absolutely is. I get fed up of the dumming down excuse by evoking a theoretical average person. I think this is very condescending of you. You can understand it but the average person might not, this is tosh. So what is your excuse to them in counting physical pins and saying "no that is not a GPIO it is a 3V3 line or a ground or a don't connect"?

I would include myself in this group of "average people". I don't need to know about the GPIO numbers. I connect my wires by counting the pins, looking on the diagram to check whether it is a usable pin or not, rather than looking at the diagram, counting the pin number, scrolling down the page and finding that pin number, and then using that GPIO number.

...

Given that, I don't see what you're complaining about: the feature that you want exists - and is easily usable - and the simple 1,2,3,4 way of numbering pins has been implemented for those for whom addresses and PCB design are knowledge they don't have, let's say children (the very people the Pi was created for). So what is your problem?


The problem is that no one technical references the pin numbers. If you reference other projects you will see the purpose of the pin not its physical location. And by creating an abstraction layer that converts from a GPIO value to a pin value means you will always have to have the same physical layout on every rev of the board. If someone was to use the Pi as a reference design they would have to make a 26 pin header and put the pins in the order that the foundation picked. Remember you are writing software that interfaces with the CPU. In a project where you have both software and hardware engineers, the software developers are given information "to talk to X device use GPIO 1, 2 and 3 to do...." It does not matter how your two pieces of hardware are actually connected.

To Grumpy Mike's point, its better to learn to do things correctly than do them easily.
IRC (w/ SSL Support): jecxjo.mdns.org
Blog: http://jecxjo.motd.org/code
ProjectEuler Friend: 79556084281370_44d12dd95e92b1d9453aba2bdc94101b
User avatar
Posts: 157
Joined: Sat May 19, 2012 5:22 pm
Location: Ames, IA (USA)
by sharpapotheosis » Sun Jun 10, 2012 2:35 pm
...by creating an abstraction layer that converts from a GPIO value to a pin value means you will always have to have the same physical layout on every rev of the board. If someone was to use the Pi as a reference design they would have to make a 26 pin header and put the pins in the order that the foundation picked...


Fair point, I hadn't thought of it like that. That said, the GPIO pins used on the current board are seemingly random (though I appreciate that they're not). Aren't the future revisions more likely to also have a 26-pin header, but connect to different GPIO pins (due to different PCB routing or different peripherals). Wouldn't it then be better to use the pin numbers rather than the GPIO numbers?
Posts: 58
Joined: Thu May 24, 2012 6:47 pm
by sharpapotheosis » Sun Jun 10, 2012 2:36 pm
Actually, scrap that: you just use your own variables that you set at the start of your program. That way you can change it without hassle. Ignore the previous question ;P
Posts: 58
Joined: Thu May 24, 2012 6:47 pm
by domesday » Sun Jun 10, 2012 3:54 pm
Well I feel that Grumpy Mike is living up to his name.

I'm not sure I am making my point well enough for people to get what I am saying. Lets clarify one thing here, the primary objective of the Pi is as an educational tool. The foundation is primarily concerned with promoting the use of high level languages such as Python and Scratch, in fact Python is the primary language that the foundation is promoting for learning programming.

Future revisions of the Raspberry Pi may well have different hardware designs this includes ...

A different expansion connector that could have a different number of pins and/or a rearrangement of the pin order.
This means that using the physical pin numbers is as Grumpy Mike and Gert says problematic because a program that references a pin number on this version would need to be changed for each future revision. Gert has elected to use the signal names i.e GPIOXX from the Broadcom datasheet as the GPIO functions are not fixed so can be re-configured for your chosen purpose.

Due to PCB routing complexities different GPIO signals may be used for a particular function on the board.
It is quite conceivable that due to changes in the peripherals or that newer versions of the Broadcom chip may provide new needed functions only on the GPIO signals that are currently used for something else. For example a new revision of the chip might have a new feature relating to new UHS SD cards that is currently assigned to a GPIO pin at the moment. It would therefore be necessary to reapropriate that signal for use with the SD card and use one of the other available GPIO signals to replace the function. So if you currently set GPIO17 high expecting to make pin 11 high you would have a problem if that GPIO17 had been re-assigned as a write-protect signal for an SD card in the next revision of the Pi.
This makes the use of internal signal identifiers as problematic as using pin numbers.

There are a set of suggested or pre-defined groupings that have been chosen.
UART, GPIO (8bit Parallel IO group), SPI, I2C.

So to my mind it makes much more sense to me in a high level language to use these suggested groupings, with the provisio that I would use PIO (or similar) to differentiate the grouping from the internal GPIO name as it causes confusion. I would therefore suggest that in python you would simply open a connection using the grouping name.

Syntax Examples ....

8bit Paralel IO group
Setup all pins on parellel IO as an output.
GPIO.setup(PIO, OUT)
Send the decimal number 3 to the parallel IO port that will be out put as a binary equivalent.
GPIO.output(PIO, 3)

Setup individual PIO pin as an output.
GPIO.setup(PIO7, OUT)
Set individual PIO pin high.
GPIO.output(PIO7, True)

UART Group
Configure UART 1 (there could be more than 1 in future) to 9600 baud
GPIO.setup(UART1, 9600)
Send data via UART
GPIO.output(UART1, My string here)

The point being that the person using this would not need to know internal memory addresses, GPIO signal assignments or pin assignments. They can set-up a simple experiment by attaching an IO board that supports parallel IO or SPI or whatever interface and write a program to control it. As long as they have a board that is compatible with the version of the Pi they have this will remain constant regardless of any signal re-routing or changes to the connector. It makes the barrier to entry much lower, not a steep learning curve where you have to understand the inner workings of the system before you can get anywhere.

If you can get some LED's flashing or a buzzer buzzing with minimal effort it is the hook in to experiment further and delve deeper. This is exactly what made the 80's micros popular. 10 print 'Hello World" will work without knowing how variables are assigned within the machine or anything complicated it just prints something on the screen. Once you have mastered these basics you can start to delve deeper. If I had to understand machine code on the BBC micro before being able to print my name on the screen I would have given up in the first five minutes.

Abstraction is not a bad thing when you have an open system that allows access to the lower levels as required.
Posts: 256
Joined: Fri Oct 21, 2011 5:53 pm
Location: UK
by Grumpy Mike » Sun Jun 10, 2012 7:45 pm
domesday wrote:Well I feel that Grumpy Mike is living up to his name.

No surprises there then.
domesday wrote:I'm not sure I am making my point well enough for people to get what I am saying. Lets clarify one thing here, the primary objective of the Pi is as an educational tool.

Yes you are making your point very clear, it is just that you are very very wrong on several fronts. You are right to say the primary objective of the Pi is as an educational tool. What you are doing is making the same right royal cock up that educators have continued to make over the years. That is attempt to simplify and hide any perceived complexity to make it easy for the little ones. Well you might not have noticed, but those such things have always been a total and utter failure. Take the ITA (Initial teaching alphabet), remember that. What a failure, it damaged many children and they still curse educators for it to this day. Then there is all the attempts to teach maths in a logical manor. They leave children unable to do simple mathematical operations. Look at the way home economics has left more than one generation of children unable to cook. And the cause of the Pi the way IT has been totally ruined.
jecxjo wrote:its better to learn to do things correctly than do them easily.

Is spot on.
domesday wrote:Future revisions of the Raspberry Pi may well have different hardware designs this includes ...
A different expansion connector that could have a different number of pins and/or a rearrangement of the pin order.

Yes this is true. So this means it is even more totally stupid to use the physical pin numbers.

domesday wrote:It is quite conceivable that due to changes in the peripherals or that newer versions of the Broadcom chip may provide new needed functions only on the GPIO signals that are currently used for something else.

This is where you are making your biggest mistake. Newer versions of the Broadcom chip is possible but very unlikely. New board revisions are more likely with different pin outs on the connector or additional signal. However have you looked at the schematic? You will see there are four GPIO inputs that just read logic levels from resistors. These are used to indicate the build number of the board. Any board that has a different connector will have a different build number readable by any software.

domesday wrote:This makes the use of internal signal identifiers as problematic as using pin numbers.

Now you lose me there why would you think that?

domesday wrote:So to my mind it makes much more sense to me in a high level language to use these suggested groupings ..........

So now you want to make it much more complicated that it actually is!!!!
Your point is wrong and bad.

domesday wrote:If you can get some LED's flashing or a buzzer buzzing with minimal effort it is the hook in to experiment further and delve deeper. This is exactly what made the 80's micros popular. 10 print 'Hello World" will work without knowing how variables are assigned within the machine or anything complicated it just prints something on the screen. Once you have mastered these basics you can start to delve deeper. If I had to understand machine code on the BBC micro before being able to print my name on the screen I would have given up in the first five minutes.

True and the Pi is EXACTLY the same in this respect, so I don't get what you are driving at. It sounds like a spurious argument.

On a BBC micro if you wanted to access the user port you had to do a know what bits in a byte corresponded to what pin on the connector and make up your byte accordingly. There was no concept of bit addressing. What we have here is an opportunity of making things simpler than the BBC but please don't dress it up in such an appalling system.

domesday wrote:Abstraction is not a bad thing when you have an open system that allows access to the lower levels as required.

It is when you use in in the way you are proposing.
User avatar
Posts: 748
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
by MattHawkinsUK » Thu Jun 14, 2012 10:42 am
I am using the physical pin numbers. At the start of a Python script is easy to assign pin numbers to aliases and use those with the GPIO function calls.

If the hardware changes in the future then I can simply update those settings at the top of the script. The pins on my Pi Model B are never going to change.

No big deal and easy to change. I got fed up trying to work out all the various random naming conventions for GPIO pins. I'm interested in the Broadcom names but when I am wiring up inputs and outputs they simply get in the way.

I created my own header pin diagram for printing out and using when playing with header pins, LEDs and breadboard.

Having read the rest of this thread .... when you have a physical LED and a physical wire you need to know what physical pin to connect it to. Once it is connected you need to control that physical pin. I don't care less what the CPU manufacturer calls the legs on their chip. Just as I don't care what bit of silicon it is connected to or what the shoe size is of the person who designed it. Knowing the Broadcom names is something I *could* find out but there is nothing big or clever making something over complicated. Grumpy Mike should probably make his own processor out of raw silicon because anything else would be hiding the true complexity of transistors and the flow of electrons through a doped substrate.
Last edited by MattHawkinsUK on Thu Jun 14, 2012 11:02 am, edited 1 time in total.
My Raspberry Pi blog and home of the BerryClip Add-on board : http://www.raspberrypi-spy.co.uk/
Follow me on Google+, Facebook and Twitter (@RPiSpy)
User avatar
Posts: 449
Joined: Tue Jan 10, 2012 8:48 pm
Location: UK
by rurwin » Thu Jun 14, 2012 10:51 am
MattHawkinsUK wrote:I created my own header pin diagram for printing out and using when playing with header pins, LEDs and breadboard.


You could do with that what I did when I was using wire-wrap: print it out actual size, punch holes in it with a needle, and put it over the GPIO pins.
User avatar
Moderator
Posts: 2887
Joined: Mon Jan 09, 2012 3:16 pm
by Grumpy Mike » Thu Jun 14, 2012 4:15 pm
MattHawkinsUK wrote:I got fed up trying to work out all the various random naming conventions for GPIO pins.

they are not random.
MattHawkinsUK wrote:I'm interested in the Broadcom names but when I am wiring up inputs and outputs they simply get in the way.

I created my own header pin diagram for printing out and using when playing with header pins, LEDs and breadboard.

Great another confusing hotch potch diagram not using the default names.

MattHawkinsUK wrote:Having read the rest of this thread .... when you have a physical LED and a physical wire you need to know what physical pin to connect it to. Once it is connected you need to control that physical pin. I don't care less what the CPU manufacturer calls the legs on their chip. ......... but there is nothing big or clever making something over complicated.

I am trying to make it simple you are the one over complicating it.

MattHawkinsUK wrote:Grumpy Mike should probably make his own processor out of raw silicon because anything else would be hiding the true complexity of transistors and the flow of electrons through a doped substrate.

That is just a reductio ad absurdum argument and not true.

If you ever want to do anything with the pin you need to know what it is called. If you need advice or you want the specification or want to change anything you need it's name. A pin can have up to seven functions, these same functions can be assigned to different pins. There is no point in calling pin by an arbitrary alternate function, you should call it by its name, it's default function. GPIO 0 is an input when the processor powers up, it is an input after Linux has finished initialising it, so why on Earth label it SDA0? It only becomes that once you initialise it to be so. Unless you know it is called GPIO 0 you don't know how to initialise it. That is why you need to know what the manufacturers call it.

Would you be happy if we called all the pins after woodland animals, mouse, shrew, mole, badger and fox. That is my reductio ad absurdum argument and is every bit as true as yours.
User avatar
Posts: 748
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
by Grumpy Mike » Thu Jun 14, 2012 4:27 pm
Grumpy Mike wrote:
MattHawkinsUK wrote:I got fed up trying to work out all the various random naming conventions for GPIO pins.

they are not random.
MattHawkinsUK wrote:I'm interested in the Broadcom names but when I am wiring up inputs and outputs they simply get in the way.

I created my own header pin diagram for printing out and using when playing with header pins, LEDs and breadboard.

Great another confusing hotch potch diagram not using the default names.

MattHawkinsUK wrote:Having read the rest of this thread .... when you have a physical LED and a physical wire you need to know what physical pin to connect it to. Once it is connected you need to control that physical pin. I don't care less what the CPU manufacturer calls the legs on their chip. ......... but there is nothing big or clever making something over complicated.

I am trying to make it simple you are the one over complicating it.
For example on you page you say:-
However only 8 of these are considered GPIO pins out of the box. The other 9 can perform more complex roles but I’m only interested in the basics.

This is simply not true all but 2 pins on that header are configured as GPIO inputs out of the box.

MattHawkinsUK wrote:Grumpy Mike should probably make his own processor out of raw silicon because anything else would be hiding the true complexity of transistors and the flow of electrons through a doped substrate.

That is just a reductio ad absurdum argument and not true.

If you ever want to do anything with the pin you need to know what it is called. If you need advice or you want the specification or want to change anything you need it's name. A pin can have up to seven functions, these same functions can be assigned to different pins. There is no point in calling pin by an arbitrary alternate function, you should call it by its name, it's default function. GPIO 0 is an input when the processor powers up, it is an input after Linux has finished initialising it, so why on Earth label it SDA0? It only becomes that once you initialise it to be so. Unless you know it is called GPIO 0 you don't know how to initialise it. That is why you need to know what the manufacturers call it.

Would you be happy if we called all the pins after woodland animals, mouse, shrew, mole, badger and fox. That is my reductio ad absurdum argument and is every bit as true as yours.
User avatar
Posts: 748
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
by jecxjo » Thu Jun 14, 2012 4:31 pm
After stepping away from this thread for a few days I think I'm a bit lost as to why people are having difficulty calling GPIO pins....GPIO pins? The convention is to reference the purpose of the pin (GPIO 0 or , UART0_RTS, etc) and the reason being is that this way you and others know why you are interfacing with that I/O. In all honesty you can name them whatever you want, but at the end of the day no one will know what you are talking about.

Its not a difficult convention to understand as long as you realize that you are writing software that interfaces with the CPU and not the board itself. That's the way its done and you'll get a lot less flack and much quicker responses if you know your terminology.
IRC (w/ SSL Support): jecxjo.mdns.org
Blog: http://jecxjo.motd.org/code
ProjectEuler Friend: 79556084281370_44d12dd95e92b1d9453aba2bdc94101b
User avatar
Posts: 157
Joined: Sat May 19, 2012 5:22 pm
Location: Ames, IA (USA)
by abishur » Thu Jun 14, 2012 5:11 pm
I kinda feel like this is an ideological debate :-P

That said, I feel like my personal opinion is more along side's Mike's. I would much rather identify the GPIO by it's real physical connection than by an abstract "This is what we renamed them". Of course, I'd also probably take those pins and renumber them as I see fit, but then at least it would be an abstraction of my own design and I'd be smart enough to use the real pin name when seeking tech support rather than my own pin names.

And that's kind the issue I'm looking at in this. There are 2 different names people might use when describing their issues. The actual names as assigned by broadcom, which is what Mike is arguing for I think, and what Matthew H actually did (I think you misunderstood what he was doing Mike ;-)) and the names as assigned by the python library. If we had set things up to use a single name then yeah, it might seem weird to some to have gpio 17 all the sudden in the strip, but they could have quickly figured it out and it wouldn't have created any bigger hiccup then the momentary, "huh?"
Dear forum: Play nice ;-)
User avatar
Moderator
Posts: 4221
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
by MattHawkinsUK » Thu Jun 14, 2012 9:57 pm
Grumpy Mike wrote:A pin can have up to seven functions, these same functions can be assigned to different pins. There is no point in calling pin by an arbitrary alternate function, you should call it by its name, it's default function. GPIO 0 is an input when the processor powers up, it is an input after Linux has finished initialising it, so why on Earth label it SDA0? It only becomes that once you initialise it to be so. Unless you know it is called GPIO 0 you don't know how to initialise it. That is why you need to know what the manufacturers call it.


I wrote a load of stuff in response to the points above but I binned them after reading this paragraph as I think this is the most constructive bit to respond to.

Now I finally see what you are saying ... and I think I agree. Honestly I think I do. The Wiki implies these functions are configured this way on power up. That Pin 3 is "I2C0 SDA" because that is how it is configured. And that Pin 8 is configured as a UART transmit. Are you saying that all the pins are actually equal on powerup and can be considered all standard GPIO? So when I used Pin 11 for an LED I could have used Pin 3 or Pin 8? And simply configured that as an output in my Python script?

The Wiki is really confusing because it does state certain pins are preconfigured.

If so I will actually update my diagram and ditch all those names and replace with GPIOXX names. My intention with that diagram was to make it simple and to help people to get something up and running hardware wise. I'm just interested in logic level input and output so don't really care for the fancy serial interfaces. If those interfaces are not really there anyway then it does seem confusing to mention them. It makes it look like you've only got 8 pins to play with. I knew you could reconfigure but the implication was that you would be going against the grain. For my purposes I would much rather have a load of inputs/outputs in a row that tip-toeing around the pins that I thought were "special".

This is probably something that helps clarify things :
BCM2835 GPIO functions
http://www.elinux.org/RPi_BCM2835_GPIOs

I think you are saying that Pin 3 should not be named as "SDA0" because some users will not be using that function so it is stupid to label something with SDA0 when it might configured as SA5.

The name needs to be a permanent label and not linked to the function you may or may not configure it to be.

Refer to it as "GPIO0 (Pin 3)" and there can be no more confusion. Obviously in time a new model may route GPIO0 to a different pin but you've got to mention pin numbers at some point before you fire up a soldering iron.

So the diagram should show 1) the physical pins numbers 2) the full set of GPIOXX names from column 1. Everything else is probably beyond the scope of a basic diagram. If you are messing with UARTs then the table is probably a better thing to print off and stick on the wall.

Grumpy Mike wrote:Would you be happy if we called all the pins after woodland animals, mouse, shrew, mole, badger and fox.

I'd probably go for Simpson's characters.

However I do think beginners and students don't need to know the names initially. They are faced with a header and need to know what bit of metal to join to their circuit and what bit of Python to type to get it to work. Everything else can come later. Including writing better code, making it future proof etc.
My Raspberry Pi blog and home of the BerryClip Add-on board : http://www.raspberrypi-spy.co.uk/
Follow me on Google+, Facebook and Twitter (@RPiSpy)
User avatar
Posts: 449
Joined: Tue Jan 10, 2012 8:48 pm
Location: UK
by Grumpy Mike » Thu Jun 14, 2012 10:17 pm
So the diagram should show 1) the physical pins numbers 2) the full set of GPIOXX names from column 1.

That is how I did it here:-
http://www.thebox.myzen.co.uk/Raspberry/Buffer_Board.html
User avatar
Posts: 748
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
by kdakin » Sat Jun 16, 2012 3:57 pm
Grumpy Mike wrote:
domesday wrote:Well I feel that Grumpy Mike is living up to his name.

No surprises there then.
domesday wrote:I'm not sure I am making my point well enough for people to get what I am saying. Lets clarify one thing here, the primary objective of the Pi is as an educational tool.

Grumpy Mike wrote: "Yes you are making your point very clear, it is just that you are very very wrong on several fronts. You are right to say the primary objective of the Pi is as an educational tool. What you are doing is making the same right royal cock up that educators have continued to make over the years. That is attempt to simplify and hide any perceived complexity to make it easy for the little ones.

[quote="jecxjo"]
I agree completely with Grumpy Mike and jecxjo. The worst way to teach is to hide things. Show people how it works using a simple example but not to the extent they can't really see causality.

Having said that let me address the issue for this post and resolve it sensibly.
This whole issue about absolute v. relative pin definitions and when/how to define them in Python or some other high level language is way over complicated.
The simple solution in any language to a "issue" like this is to provide an external mapping using a one-to-one definition "file". That way, all you need to do to "re-align" the physical pins (in case of later changes to hardware assignments) is to adjust the mapping definitions with a simple line editor. The program itself always stays the same and undertakes the physical assignment at I/O execution using the internal (program) function as an index. The structure of the mapping file can be extremely simple comma separated values like this example below incorporating a comment column so it is clear what the function/ physical assignment is.
Something like this - just to make the point clearer.
0,0, # NOOP (fixed internal function number [comma] physical pin [comma] #comment)
1,1, # function x, GPIO pin 1
2,7, # function y, GPIO pin 7
3,26, # function z, GPIO pin 26
If you really want to give the function numbers some symbolic/abstract name in the program, you can do that also - but at that level the abstract name equates first of all to a relative function number (an index) and only ever to a physical one via the external map file - at the point of the I/O execution (that should nearly always be in a sub-routine anyway). If the pin functions are held in variables that are not "bit values", the sub-routine also combines them to the necessary binary octets etc. This concept is not difficult - it is simple stuff and, once done, is a template for all other program sub-routines you might write for ever and a day.
It has always irritated me that programmers scatter their actual I/O throughout their programs and invoke "absolute" values embedded in their code instead of concentrating these into an I/O sub-routine. I have used modular programming for more than 40 years (long before OOP coding supposedly spearheaded the idea - together with "data hiding" [just what you need in teaching!] ). On the (rare) occasions a program has had to change because of a new database or similar, all that is usually required is a relatively simple change the I/O sub-routine. For I/O pin re-allocation, this should not necessary even. You might guess from the above that I am not an fan of OOP either and believe it has damaged IT education (through abstraction and other tortuous routes) to the point of failure.
If you don't understand the fundamentals of any industry, get out of the "kitchen" (or the garage or the laboratory..) or else get down and learn them properly before venturing back in.
Posts: 54
Joined: Sat Mar 24, 2012 7:20 am
by Joefish » Thu Jun 21, 2012 2:14 pm
I think I'm actually getting around to agreeing with Grumpy Mike, though if it'd been a little less confrontational a lot of people may have come round earlier...

I have no problem with his diagram that has the pins numbered 1-26 and the GPIOxx labels next to them. This seems pretty clear to me. Clearly the 3V3 5V and GND pins need a label, and so it follows the rest of the GPIO labels are clear. And I gather the Python library can use either of these two to reference a pin.

It's the Wiki with the 'default' behaviours that aren't a default at all that needs to be wiped out and have someone start again. The sooner this is done the better.

It would be helpful to have documentation that points to the built-in pull-up/down whatever arrangements on the pins that are designed for I2C etc., but the implication that they're only for I2C (when I think they're crying out to have microswitches clipped on for one-click gaming) is highly misleading.

As for education, a single layer of extra info on top of the pin numbers - I don't have a problem with. However, I do think kids are better taught one layer of complexity at a time, rather than trying to teach everrything to its most complicated depth up-front. Try finding anything kids are taught in science that isn't just a convenient lie for the time being. Arguably, that's all science is at any level!
Posts: 95
Joined: Wed Jan 25, 2012 10:31 am
by NetherWyndham » Fri Jun 29, 2012 1:59 pm
The thread started off informative and rapidly got confrontational and rather silly.
Those indulging in pedantry would do well to ensure that their standard of spelling and grammar matches the clarity they demand in others.
Posts: 1
Joined: Fri Jun 29, 2012 1:56 pm