gpio pin configuration.


Marcus Shawcroft <marcus.shawcroft@...>
 

Hi,

The current include/gpio.h interface allows for basic configuration of
a gpio pin.

The nRF5 hardware supports three different configurable drive
strengths on each pin, independently for 0 and 1 outputs. The
relevant manual describes these drive strengths as standard, high and
disconnected. All permutations are supported with the exception of
disconnected on 0 output + disconnected on 1 output.

The current nRF5 driver simply hardwires the standard drive stength
for both 0 and 1 outputs.

Extending gpio.h to allow selection of at least some of the other
modes is a pre-requisite for an nRF5 I2C driver. (The two pins used
for I2C need to be placed into one of the disconnected modes).

I'm looking at adding two new fields into the gpio configuration
'flags', one field to configure the 0 output drive strength, the other
field to configure the 1 output drive strength.

Something along the lines of:

#define GPIO_DS_0_STANDARD 0 <<12
#define GPIO_DS_0_HIGH 1 << 12
#define GPIO_DS_0_DISCONNECTED 2 <<12

#define GPIO_DS_1_STANDARD 0 <<14
#define GPIO_DS_1_HIGH 1 << 14
#define GPIO_DS_1_DISCONNECTED 2 <<14

The standard drive strength flags are deliberately choosen to be 0
such that any existing user of the interface that does not specify a
drive strength flag will get the current behaviour of 'standard' drive
strength.

There are three possible routes to define the behaviour of a driver
for HW that does not support any of these modes:
1) Default to standard drive strength
2) Return ENOSUP from configure.
3) __ASSERT

Of these, 2) feels like the wrong answer, what would an app do if it
got -ENOSUP, 3) feels rather inflexible and awkward. Hence I'm
tempted to go with 1).

The terms 'standard' and 'high' are arbitrary. They are inflexible if
we have HW that perhaps supports more than two drive strengths. From
an applications perspective it is not clear what contract the a driver
is really offering.

I've been pondering this on an off for a while and havn't been able to
come up with a more elegant scheme.

Thoughts welcome on a better approach??

Thanks
/Marcus

Join devel@lists.zephyrproject.org to automatically receive all group messages.