GPIO module calling standards

Does anyone have any thoughts about the way the GPIO module sets the OE for example. On the Beagle it needs logic 0 to set as output, but on the Pi it uses logic 1. I have just followed the way the underlying hardware sets this ATM.
This means that code will have to be written by machine type (as it does for which GPIO’s are available).

I think you should make the APIs consistent across all machine types wherever possible. That way a simple program that just uses the SWI interface to interact with the GPIOs can easily be ported from one platform to another just by changing the GPIO numbers it’s using.

For lower-level interfaces (your module provides pointers to the GPIO registers, IIRC?) I guess there’s not much that you can do except leave it down to the application developers to deal with any hardware differences. Either that or provide something at a slightly higher layer, e.g. pointers to functions to read/write the different register types, using a consistent API across all platforms.

When I get a chance I’ll also hook up the GPIO HAL device for the Pi (maybe tonight if you’re lucky!)

Also I suspect this kind of discussion is more suited to the code review forum than community support.

Jeffrey, that was my thought, but… which standard do I make the default.
The Pi (hopefully) will get more users, so do we go with logic 1 as output, so that its less confusing ?
That means any existing (if any other than me!!) users will need to modify their code.
Yes, the module does return the pointers, so, as they say, buyer beware!!!
The HAL device will be nice, as at the moment the module checks and if it doesn’t find a suitable machine it defaults to the Pi…
If someone with access wants to/can move this thread please do.

Don’t know if this helps, (probably not!)
On the Microchip PIC devices, it’s 0=Output and 1=Input. Might be a memory aid. Difficult one.
Having said that, just looked at all of the examples on the
elinux.org Rpilow level peripherals
and most of the coding for direction seems to be text and not setting bits.
You could always ask Broadcom if they’ll redesign their chips and recall those already out there! :)

You could always ask Broadcom if they’ll redesign their chips and recall those already out there! :)

Yes, sounds like the ideal answer…;-)

It seems most of the rest of the “world” do use 0=Output, so unless there’s any objections….

It seems most of the rest of the “world” do use 0=Output

Sorry to throw a spanner in the works… but the 6522 VIA DDRA/DDRB uses 0 for input (high impedence), and 1 for output.
To use 0(utput) and 1(nput) makes sense nmemonically, however there is a trap. I have browsed online the datasheets for some MCUs, PICs, etc and it seems that modern chips seem to prefer O(utput)/1(nput)…

Now, the thing is (and maybe new hardware is immune) the older hardware set the default power-up state to high impedence input (logic zero) so there is less/no chance of spurious output glitches at power-up.

There’s no big deal to flipping/inverting bits in firmware/drivers – as anybody who has had to deal with parallel ports will know well. ;-)

Best wishes,

Rick.