Re: gpio pin configuration.


Marcus Shawcroft <marcus.shawcroft@...>
 

Hi Tomasz,

On 15 December 2016 at 10:31, Tomasz Bursztyka
<tomasz.bursztyka(a)linux.intel.com> wrote:

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

1 << 13
The three modes standard, high, disconnected are mutually exclusive
hence the proposal to represent them as three values encoded in a two
bit field, the fourth possible encoding effectively becomes reserved
for future use. The two separate fields allow for the behaviour of
the pin to be configured independently when outputting a 0 or a 1. If
we were to stick with boolean flags only then we could do something
like:

#define GPIO_DS_0_HIGH 1 << 12
#define GPIO_DS_0_DISCONNECT 1<<13
#define GPIO_DS_1_HIGH 1 << 14
#define GPIO_DS_1_DISCONNECT 1<<15

(your point about BIT() taken).

In this scheme:
- the presence (or absence) of *_HIGH selects between the HWs standard
drive strength and a high/alternative drive strength (if supported).
- the {0,1}_DISCONNECT flag selects a high impedance/disconnected
behaviour for 0/1 output respectively, hence this flag would always,
irrespective of hw/driver, be mutually exclusive with the {0,1}_HIGH
flag.

I think the first view with multiple mutually exclusive values in a
single field to be the more intuitive of the two representations, but
I don;t feel strongly on this issue.

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.

What about GPIO_DS_DFLT_* and GPIO_DF_ALT_*
0 and 1 are not telling much.
I've failed to parse exactly what you mean here, either:
- you are referring to the 0 << 12 vs 1 << 12 and suggesting that the
GPIO_DS_[01]_STANDARD serves no purpose since it conveys no additional
information over and above simply not specifying any flag at all.
or
- you are referring to the two groups of flags GPIO_DS_0_* and
GPIO_DS_1_*, in which case I failed to clearly articulate the
intention that the mode/behaviour of the pin should be independently
configurable depending whether it is currently outputting a 0 or
outputting a 1 (nrf5 HW is one example of HW that supports this degree
of flexibility).


Cheers
/Marcus

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