Using GPIO

[Alan Adams]

Hi

Does anyone here understand the documentation for the GPIO module? I'm
completely confused. There was a module (pre 2017 it seems) with a host of
SWIs which were more or less descriptive. The replacement seems to only
have about ten SWIs and I can't make out from the only documentation (a
StrongHelp file) which ones would do what I need.

On an rpi, I need to enable two pins as inputs, causing an interrupt.
(Using a change of state event will not be fast enough, as that has to be
polled for).

I need to create a small module which will react to the interrupt, decide
which pin it was, and store the current clock time, then change a
pollword. (I'm assuming here that servicing an interrupt requires a
module.)

I have the hardware manual, so I know the hardware is capable of this.
What I can't see is how the GPIO module helps. Maybe it doesn't... Ideally
it would already be capable of handling the interrupt for me, but I have
doubts about that.

This is likely to be a learning experience for me, as I've never written
any C. At the monment I'm thinking it would be easier for me to write it
in assembler, especially as I have a module to use as an example - the
Socketwatch module is also in assembler. I have in the past written
assembler for VAX, Z80 and 6502. The Z80 was a language ROM providing a
complete terminal emulator, including enlarged buffers hooked into the
vectors, so not exactly trivial.

[s***@elesar.co.uk]

Post by Alan Adams
Does anyone here understand the documentation for the GPIO module? I'm
completely confused. There was a module (pre 2017 it seems) with a host of
SWIs which were more or less descriptive. The replacement seems to only
have about ten SWIs and I can't make out from the only documentation (a
StrongHelp file) which ones would do what I need.

Except for GPIO_Features, the subset of 10 to which you refer all existed in the myriad of 107 previously. Those 10 are the common ones across all platforms which support GPIO (eg. you could prototype on a Beagleboard and deploy on a Pi).

If you remember your BBC Micro 6522 VIA they should be relatively easy to understand:
ReadData/WriteData = the data register
ReadOE/WriteOE = the data direction register

The ReadMode/WriteMode calls are extras needed because most pins on modern micros can also be multiplexed with things other than GPIO, for example it may be possible to get a UART to come out on the same pins by changing the mode.

The ReadEvent/WriteEvent calls are to poll for transitions that were captured (based on what you asked them to watch out for with WriteMode) - most analogous to the handshaking strobe lines on the beeb.

The Info/Features calls are there to allow you to enumerate and find out features programmatically. You could ignore them, but then you'll be tied to a certain pinout on one board (beware! there are even variations from Pi to Pi between models).

Post by Alan Adams
On an rpi, I need to enable two pins as inputs, causing an interrupt.
(Using a change of state event will not be fast enough, as that has to be
polled for).
I need to create a small module which will react to the interrupt, decide
which pin it was, and store the current clock time, then change a
pollword. (I'm assuming here that servicing an interrupt requires a
module.)
I have the hardware manual, so I know the hardware is capable of this.
What I can't see is how the GPIO module helps. Maybe it doesn't... Ideally
it would already be capable of handling the interrupt for me, but I have
doubts about that.

The GPIO module doesn't currently despatch interrupts, you'd have to do that yourself. The GPIO SWIs also have the disadvantage that they're single bit wide, so tend to result in lots of very verbose code. Underneath the GPIO module is the GPIO HAL interface - that's 32b port wide which makes manipulating several bits at once much easier.

It's definitely possible to service interrupts, our parallel port HAT
http://shop.elesar.co.uk/index.php?route=product/product&product_id=76

does just that for the printer ACK line.

Post by Alan Adams
This is likely to be a learning experience for me, as I've never written
any C. At the monment I'm thinking it would be easier for me to write it
in assembler, especially as I have a module to use as an example - the
Socketwatch module is also in assembler. I have in the past written
assembler for VAX, Z80 and 6502. The Z80 was a language ROM providing a
complete terminal emulator, including enlarged buffers hooked into the
vectors, so not exactly trivial.

Provided your handler is in permanently paged in memory (such as the RMA) you don't particularly need to write a module. An application could claim some RMA, install a handler, then poll a shared flag - probably simpler than learning a new programming language!

Recommend buying a reset button for your Pi, there will be plenty of crashes along the journey!
Robert.

[Alan Adams]

Hi

Thanks for the reply. Comments interleaved below.

Post by s***@elesar.co.uk

Post by Alan Adams
Does anyone here understand the documentation for the GPIO module? I'm
completely confused. There was a module (pre 2017 it seems) with a host of
SWIs which were more or less descriptive. The replacement seems to only
have about ten SWIs and I can't make out from the only documentation (a
StrongHelp file) which ones would do what I need.

<snip>

Post by s***@elesar.co.uk

Post by Alan Adams
On an rpi, I need to enable two pins as inputs, causing an interrupt.
(Using a change of state event will not be fast enough, as that has to be
polled for).
I need to create a small module which will react to the interrupt, decide
which pin it was, and store the current clock time, then change a
pollword. (I'm assuming here that servicing an interrupt requires a
module.)
I have the hardware manual, so I know the hardware is capable of this.
What I can't see is how the GPIO module helps. Maybe it doesn't... Ideally
it would already be capable of handling the interrupt for me, but I have
doubts about that.

The GPIO module doesn't currently despatch interrupts, you'd have to do
that yourself. The GPIO SWIs also have the disadvantage that they're
single bit wide, so tend to result in lots of very verbose code.
Underneath the GPIO module is the GPIO HAL interface - that's 32b port
wide which makes manipulating several bits at once much easier.

So would it be feasible to use the HAL interface? Is it documented
anywhere?

The alternative would seem to be to use the GPIO module to set the
registers up, then access the hardware directly when an interrupt
occurred.

(The third alternative is not to use a pi, but build some dedicated
hardware, which isn't as much of a step as it might seem.

BTW does the gpio clock pulse output slow down when the throttling takes
place?

Post by s***@elesar.co.uk
It's definitely possible to service interrupts, our parallel port HAT
http://shop.elesar.co.uk/index.php?route=product/product&product_id=76

<snip>

Post by s***@elesar.co.uk
Recommend buying a reset button for your Pi, there will be plenty of
crashes along the journey!
Robert.

I'd forgotten the availability of a reset on board. I'm well aware of
crashes with this sort of code. The VAX stuff was kernel-mode, so I had to
write it, test it, and get it live during the Christmas shutdown.
Restarting a VAX each time took around 10 minutes.

[Alan Adams]

[Posted and mailed]

Post by s***@elesar.co.uk

Post by Alan Adams
Does anyone here understand the documentation for the GPIO module? I'm
completely confused. There was a module (pre 2017 it seems) with a host of
SWIs which were more or less descriptive. The replacement seems to only
have about ten SWIs and I can't make out from the only documentation (a
StrongHelp file) which ones would do what I need.

<snip>

Post by s***@elesar.co.uk
It's definitely possible to service interrupts, our parallel port HAT
http://shop.elesar.co.uk/index.php?route=product/product&product_id=76
does just that for the printer ACK line.

<snip>

So after some experimanting, I've got SYS "GPIO_Info" to produce output.

This seems to refer to the pin numbers on the physical connector, and I
think it will adjust these depending on what model it is running on. As I
have a pi 1B, 2B and 3B, I can check that.

However to handle the interrupt, it seems I either need to use the HAL
interface or the hardware directly. Both seem to refer to the pair of
32-bit registers which give 64 in/out bits. How do I find out which of
these corresponds to the physical pin - or do I need to?

I could I suppose try setting each in turn as an output, and causing it to
toggle, then look for the pin changing with an oscilloscope.

I have a feeling my program is going to end up containing a set of mapping
tables for the different models. That then leaves me to work out how to
identify the model. How can I distinguish between different pi models?

[s***@elesar.co.uk]

Post by Alan Adams

Post by s***@elesar.co.uk

Does anyone here understand [...] GPIO

<snip>

Post by s***@elesar.co.uk
It's definitely possible to service interrupts, our parallel port HAT
http://shop.elesar.co.uk/index.php?route=product/product&product_id=76
does just that for the printer ACK line.

<snip>
So after some experimanting, I've got SYS "GPIO_Info" to produce output.
This seems to refer to the pin numbers on the physical connector, and I
think it will adjust these depending on what model it is running on. As I
have a pi 1B, 2B and 3B, I can check that.

No - GPIO_Info,&4C4C5546 (ie. "FULL") returns logical pin numbers as they come out of the side of the system on chip. In the case of the Pi some of those end up on the GPIO header.

There should be no need to distinguish Pi models since the nice Pi people made the 40 pin header a superset of the 26 pin one. As shown here
https://siminnovations.com/wiki/index.php?title=General_Raspberry_Pi_I/O_pin_explanation

Post by Alan Adams
However to handle the interrupt, it seems I either need to use the HAL
interface or the hardware directly. Both seem to refer to the pair of
32-bit registers which give 64 in/out bits. How do I find out which of
these corresponds to the physical pin - or do I need to?

No - see above. Nothing in GPIO_ SWIs talks about pin numbers 1-40 on the header.

Post by Alan Adams
I could I suppose try setting each in turn as an output, and causing it to
toggle, then look for the pin changing with an oscilloscope.

*GPIODevices

also lists the current state.

Post by Alan Adams
I have a feeling my program is going to end up containing a set of mapping
tables for the different models. That then leaves me to work out how to
identify the model. How can I distinguish between different pi models?

You don't need to. The design of the GPIO SWIs insulates you from having to grub around with mapping tables and model numbers. Want to wiggle pin 11 on the connector? That's GPIO17, and that's the currency to use with GPIO SWIs, 17,
Robert.