Pi GPIO in RISC O/S

On topic, it seems like people are describing the re-arrangement of GPIO pin use on Pi boards as an almost random item. Why isn’t everything the same on every model of Pi?

You have the physical pin number, the logical GPIO number and then the “Wiring Pi number” which Wiring Pi decided to adopt to “simplfy” things! The logical GPIO number doesn’t always map to the same pin on every Pi (eg. the very original Pi had GPIO 0 on Pin 3, but later models replaced GPIO 0 with GPIO 2).

Also GPIO_Info returns “logical GPIO pin number” and “physical GPIO pin number”, which on my Pi 3 are always the same, and seem to be what you call “logical GPIO number”.

I’d be interested to hear if they are ever different!

I’m not sure how it defines “logical GPIO pin” & “physical GPIO pin”. I was using “physical” to mean actual metal pins 1-40 and “logical” to mean GPIOs 2-27 which appear electically on some of the physical GPIO pins (the other ones being power & ground pins).

The StrongHelp documentation does, indeed, still need a bit of attention. For example, the page about GPIO_WriteMode says that bits 0-4 of the new mode setting are “mode from pin info” which links to the page about pin info which says that at offset +9, bits 0-4 are the “mode number for GPIO_WriteMode”. Bit of a circular reference there. So far as I can tell (from the earlier version of the StrongHelp manual which I’ve now overwritten with the new one), the lsb of the mode number sets the pin to be an input (0) or an output (1)… which duplicates the function of GPIO_WriteOE, but with inverted logic… doesn’t it? So why do we need to have GPIO_WriteOE? other than that it will now break many people’s code if it gets removed. Or have I missed something important? If it’s OK to do it that way, I’d prefer to used GPIO_WriteMode to set whether pins are IN/OUT simply because I can then set the pull-up/down for inputs at the same time.

This modified version of some of Chris Hall’s code, does what I expect, i.e. light LEDs attached to pins 24, 25 and 8, cycling through them when pin 7 is grounded through a switch.

   10 REM >GPIO_Test
   20 REM
   30 gpio%=TRUE 10 REM >GPIO_Test
   20 REM
   30 gpio%=TRUE
   40 LOCAL ERROR
   50 ON ERROR LOCAL gpio%=FALSE
   60 IF gpio% THEN RMEnsure GPIO 1.00 Error GPIO Module not present
   70 RESTORE ERROR
   80 IF gpio% THEN
   90   SYS "GPIO_Info" TO low%,high%,list%
  100   PRINT "Lowest=";low%;" highest=";high%
  110   :
  120   REM Set pin 25 TO OUTPUT
  130   REM Set pin 24 to OUTPUT
  140   REM Set pin 8 to OUTPUT
  150   REM Set pin 7 to INPUT, pull UP (mode= 0+32+64=96=&60)
  160   SYS "GPIO_WriteMode",25,1
  170   SYS "GPIO_WriteMode",24,1
  180   SYS "GPIO_WriteMode",8,1
  200   SYS "GPIO_WriteMode",7,&60
  210REM Read & print I/O status of pins 7,8,24,25
  220   SYS "GPIO_ReadOE",25 TO pin25%
  230   IF pin25%=0 THEN PRINT "Pin 25 is currently an output"
  240   IF pin25%=1 THEN PRINT "Pin 25 is currently an input"
  250   SYS "GPIO_ReadOE",24 TO pin24%
  260   IF pin24%=0 THEN PRINT "Pin 24 is currently an output"
  270   IF pin24%=1 THEN PRINT "Pin 24 is currently an input"
  280   SYS "GPIO_ReadOE",8 TO pin8%
  290   IF pin8%=0 THEN PRINT "Pin 8 is currently an output"
  300   IF pin8%=1 THEN PRINT "Pin 8 is currently an input"
  310   SYS "GPIO_ReadOE",7 TO pin7%
  320   IF pin7%=0 THEN PRINT "Pin 7 is currently an output"
  330   IF pin7%=1 THEN PRINT "Pin 7 is currently an input"
  340
  350   PRINT "push button to cycle LEDs"
  360   led%=0
  370   REPEAT
  380     REPEAT: SYS "GPIO_ReadData",7 TO pin7% :UNTIL pin7%=0
  390     led%=(led%+1)MOD3
  400     SYS "GPIO_WriteData",25,0
  410     SYS "GPIO_WriteData",24,0
  420     SYS "GPIO_WriteData",8,0
  430     CASE led% OF
  440       WHEN 0:SYS"GPIO_WriteData",25,1
  450       WHEN 1:SYS"GPIO_WriteData",24,1
  460       WHEN 2:SYS"GPIO_WriteData",8,1
  470     ENDCASE
  471     PRINT"LED ";led%;"   ";:VDU13
  480     REPEAT: SYS "GPIO_ReadData",7 TO pin7% :UNTIL pin7%=1
  490   UNTIL FALSE
  500 ELSE
  510   PRINT "GPIO module not present"
  520 ENDIF
  530 END

It can get worse. I’ve just spent two days working through some working, well commented code to drive part of the GPIO which exists on the Wandboard inside the ARMX6. It was written mostly in BASIC with small sections in assembler, and all I wanted to do was convert a small subset to mostly assembler, with just one or two calls from BASIC, so that I could operate 4 pins.
There, pin 4 is described internally as bank3, pad 1, and the controls need a mux offset of &140, and a mask of 1<<11. The next pin has a mask of 1<<27, then 1<<26 and last 1<<8, each with different mux offsets. The GPIO module is hiding all that for you on the RPI. The 8 pins on one side of that connector actually come from a mixture of register banks 1,3,4,6 and 7.
I have a suspicion that the mapping of chip pins to connector pins is whatever was easiest to lay out on the PCB. This may also apply on the RPi.

So on the Wandboard, I’ve got LED drivers connected to GPIO pins 6 and 7 on the JP4 connector on the board. I can, in software, toggle both of these to 0 or 1 output. However pin7 low seems to want to be at around 1 volt into 10k, so the LED there stays lit. Adding a 4.7K pulldown resistor allows that LED to be switched on and off correctly. Pin 6 goes low to around 0 volts, as I would have expected.

I have a recollection that some of the GPIO controls allow internal pullup or pulldown to be specified (on rPi). As the CPU on the Wandboard is the same as some PIs, I assume the same would apply there too. I’m wondering whether pin 7 is defaulting to internal pullup, while pin 6 defaults to pulldown. Is this likely, and if so, how would I go about reconfiguring it?

If the pin is set to output, then its pull-up or pull-down status (these are about 60k Ohm remember) is irrelevant.

If the pin is set to output, then its pull-up or pull-down status (these are about 60k Ohm remember) is irrelevant.

That corresponds with chapter 28 of the IMX6DQRMr2_part1.pdf document.

Which leaves me wondering why one of the outputs seems to want to be fairly high when set low, while still going a lot higher when set high?

I might have to add some more wires, so I can test the 3 remaining gpio pins on that connector. Hardware fault?

From the symptoms, it looks to me as if you think you’re altering the output level but in fact you’re altering Output Enable.

From the symptoms, it looks to me as if you think you’re altering the output level but in fact you’re altering Output Enable.

I see what you mean. However I’m using the same functions on three pins, and only one behaves like this. It’s complicated, because this is on an ARMX6, which does have a version of GPIO but doesn’t have GPIO module support.

Step one is to map the mux register and to map the base register for bank 3. The output enable register is then at an address 4 bytes above the base register, while data is sent or received using the base register.

To setup, I first write to the pad register, using the mux base address, with the parameters for each of 4 pins. For these to be GPIO pins, I need to set option 5.

Then I write to the output enable register for all 4 pins, 3 as output, 1 as input.

Then I can repeatedly write to the data register for the three output pins, and read back the data register for the input pin.

When I write a 1 to the data registers, all three pins go high.
When I write a 0 to the data registers, two pins drop to 0 volts, one drops to 1 volt (approx). I can get rid of the offset either with a series diode, or a pulldown. 10K is insufficient pulldown, 4.7K works.

Is it possible to read back from the output enable register to verify what you think you’ve written?

Is it possible to read back from the output enable register to verify what you think you’ve written?

There’s something in the manual about reading back from that register, and it returns something other than the setting you’ve just made – I think.

“While the GPIO direction is set to input (GPIO_GDIR = 0), a
read access to GPIO_DR does not return GPIO_DR data.
Instead, it returns the GPIO_PSR data, which is the
corresponding input signal value.”

I’m not sure what to make of that. I think in effect the GPIO_DR register is write-only, while the GPIO_PSR is read-only, and they share an address.

A pseudocode description to drive 4'b0101 on [output3:output0] is as follows:
// SET PADS TO GPIO MODE VIA IOMUX.
write sw_mux_ctl_pad_<output[0-3]>.mux_mode, <GPIO_MUX_MODE>
// Enable loopback so we can capture pad value into PSR in output mode
write sw_mux_ctl_pad_<output[0-3]>.sion, 1
// SET GDIR=1 TO OUTPUT BITS.
write GDIR[31:4,output3_bit,output2_bit, output1_bit, output0_bit,] 32'hxxxxxxxF
// WRITE OUTPUT VALUE=4’b0101 TO DR.
write DR, 32'hxxxxxxx5
// READ OUTPUT VALUE FROM PSR ONLY.
read_cmp PSR, 32'hxxxxxxx5

I’m not doing the loopback bit, as the code I’m basing this on doesn’t do that, and I’m not sure what the “.sion” means.

It’s also possible you’re swapping the data direction instead of the output state.

It’s also possible you’re swapping the data direction instead of the output state.

Yes, I understood that, and it might produce the described symptoms. However, it should therefore produce them on all outputs, which it doesn’t, and if it’s switching it back to an input, the pullup resistor value is far too low – I’d estimate around 1K.

I’ll dig into it some more later, although probably not today.

So a quick test shows that it is something in my software. I’ve gone back to the original example code, and removed a couple of links on my circuit board so that the pins were independent, and all 4 behave as they should when used as outputs.

I did notice however that this pin is at the mid-voltage level as soon as the computer powers up. This raises the possibility that I’m not setting the pins up properly, rather than driving the outputs incorrectly.

More detective work needed.

Just a thought. Page 1423 of the manual talks of GPIO output Drive Strength and Open Drain operation. Is it possible you’ve got the two pins set up differently. The GPIO-07 control register detail is on page 2482

Is it possible you’ve got the two pins set up differently.

If it is, then it’s because that’s the default setting. That second page reference might be useful though, if I can work out what address to use for the register. Now got that. I’ve gone through the sample code, which as I said, works, and nowhere does it access the control register.

At the moment, the original sample code works correctly, while mine, which uses the same assembler routines, but called from assembler instead if from BASIC, doesn’t work correctly, but is, I think, consistent. I’ve added logging to the assembler functions in both cases, recording which was called, and the entry registers, and I’m comparing the listings. I can’t find anything different so far, but I’m wondering whether the faster sequence of calls from assembler might be involved. There’s bits in the manual talking about needing “two wait states”, but I don’t know what they mean by wait states. Is this a delay that the hardware controls, or am I supposed to count something down?

THe assembler routines called from BASIC, start with OS_EnterOs and end with OS_LeaveOs. I’m calling those in the outer assembler routines, because eventually this will be run as a callback, and that’s already in SVC mode.

So far I haven’t read all 5000 odd pages of the manual. All the GPIO stuff *seemed" to be in chapter 28, but you’ve pointed out some more relevant stuff in chapter 36. I wonder what else might be hidden somewhere in there?

And pin 7 is GP3-08 on JP4 connector pin 16, so I’m using register 3 of the GPIO. I assume the pad control register is number 3 too, page 2473, and also the mux_control_pad on page 2109 is also for GPIO 3. Both of these could affect the pin, but as I said the working software doesn’t touch them, and my non-working version doesn’t touch them either. (The sion reference I didn’t understand is on page 2109. )

And now I think I’ve found the problem. The sample software had the wrong mux register offset for pin 7, but still worked. It also worked when I corrected it. My software works provided I have the correct offset.

Instead of using IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA08 is was using IOMUXC_SW_MUX_CTL_PAD_EIM_AD08, while using the correct addresses for the other pins. Weird that the sample software worked.

Getting closer, but not quite there yet. As long as the sample code has been run first, then as long as the processor remains powered up, my code works. However starting from cold my code doesn’t work.

The sample program runs a full setup sequence before asking which test to run. Mine does the setup part that seemed necessary for the 4 pins I’m actually using. It may be that some part of the setup would benefit from being run twice, or with a delay between setup and use. I don’t think I’m missing out any of the setup steps for those 4 pins.

More checking shows that the wrong offset is being used for two of the pins, not just one – unless I’m misunderstanding the documentation. The register description of the apparently wrong registers says something like “this is part of a chain”. Huh?

Still, it gives me something to work on tomorrow…

There’s bits in the manual talking about needing “two wait states”, but I don’t know what they mean by wait states.

I’m not familiar with that CPU, but there are limitations in other CPUs (different manufacturers, so not necessarily comparable) as to how fast one can access multiple peripheral registers without the internal queue getting out of order, so a spinlock might make it behave differently – it’s easy to implement and so worth a try. I suppose assembly language makes it more likely to trip over that sort of problem.

Instead of using IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA08 it was using IOMUXC_SW_MUX_CTL_PAD_EIM_AD08,

Thinking about it overnight, it seems that to get my bit to work, I need to run the original sample code, then mine. If in mine I access the AD08 register as used in the sample, it doesn’t work. If I use the DATA08 register it does work.

Edit:
The reference to “a chain” in the manual makes me wonder whether I need to set up both. However checking carefully, the AD08 register is the one that sets output strength among other things.

So a few more things to try.

So five days later, and now it works. The odd thing though is that I didn’t change anything, at least as far as I can see.

I came here looking for a “simple” primer into how I can drive IO via the GPIO pins on a PI Zero - I “see” that it’s not as easy as anticipated……

Forgive the obviously noob Q’s

I see how I can drive IO to light LEDs and respond to switch toggles….. from the example in the Wiki

(Crosses fingers)…. Where can I find anything to help demystify how I could possibly access I2C devices (say things like this: https://www.amazon.co.uk/AZDelivery-Humidity-Temperature-Interface-Raspberry/dp/B07PFHM9HN/ref=sr_1_3?dchild=1&keywords=I2C+temperature&qid=1618258818&sr=8-3)

Use case - in class to teach coding and interfacing with the real world and dont want to go down the arduino type routes…..

Cheers
Glen

Where can I find anything to help demystify how I could possibly access I2C devices

I wouldn’t say “demystify” for this, but it’s a starting point.

https://www.riscosopen.org/wiki/documentation/show/IIC_Control

The point being that you don’t use the GPIO module for it. You could, I think, but then you would be doing a lot of low level stuff yourself.

You’ll see a reference to IIC_OP in there. It’s the more recent interface, but adds complexity that I think you don’t want for your usage.

You can avoid problems with pin numbers and blowing up your Pi by using an IIC port expander. This should be plenty quick enough anything in the classroom.

There have been several add-ons using the MCP23017 chip, with two 8-bit ports, and they can be chained for more if you really need them. They are pretty cheap.

There are others here who have done some elaborate things with them and in the early days I used the SliceOfPi. I have a very small BASIC library for controlling them and I also wrote a module to provide SWIs to do much the same thing.

I hope they might be of use.

You can avoid problems with pin numbers

Ouch!

Sorry, that would be “ouch, ouch” really :)
Yes, I know it is “the numbering of the pins” or “pin numbering”