[En-Nut-Discussion] What is the best way to deal with different I/O pin configuration on different boards

[Harald Kipp]

Hi Ole,

On 11.10.2012 17:53, Ole Reinhardt wrote:

> a) Pins were configured using the configurator
> b) Pins were configured to a fixed configuration, sometimes specific to 
>    a single board

...

> Both of the above mentioned ways have disadvantages:
> 
> a) Ends up with a lot of settings in the configurator which is sometimes
>    quite confusing and not very obvious to new users that want to use
>    Nut/OS on their own (new) board.
> 
> b) is not portable at all

Regarding a) I created the different thread, where I explained the
misuse of the GPIO API and its configuration capabilities.

Regarding b) I think that your list is incomplete.

b1) Drivers may refer to on-chip interfaces (e.g. LCDs or image sensors)
which are rarely implemented. All GPIO specific settings (enabling
peripherals etc.) may be hard coded.

b2) Drivers may refer to often implemented on-chip interfaces, which
vary among members of a specific target. Hard coding might be
acceptable, but some kind of (minimized) configuration would ease
implementation of new family members.

c) Drivers may refer to external chips. This is then mostly board
specific. Right now, these definitions are set in the conf file of the
board and partly in the board initialization. If a board is supported,
users don't need to change that.


> On the arm architecture pin setup is mostly done by defining a list of
> I/O pin settings and to initially set them up during boot time in the
> board init file.

This is how it was done. Today, board init files will be rejected after
Linus became upset by the number of redundant changes in the ARM tree
and threatens to entirely remove ARM support from the kernel.


> Beside of that, some platform drivers provide a so called "plaform data"
> struct which is initialised and assigned to the device struct right
> before initialising the driver. This platform data is set at a reference
> in the DBC struct of the driver and the driver can access this struct
> later at any time it needs the informations.

Not sure, if that is the same that I have in mind. AFAIK, a so called
flattend device tree (FTD) is passed from the boot loader to the kernel,
which contains all the features that the board provides. Note, the
board, not the CPU.


> Further I find the concept of the platform data which could hold driver
> specific default configurations for each board quite appealing.
> 
> They could hold for example the default baud rate etc. for a UART or the
> MAC address for the network interface and the default ID of a I2C
> device.

There are probably 99 ways to implement this and 99 possible pitfalls.
Do you have any more specific details yet, or just the general idea?


> This way we could move lots of configuration settings out of the
> configurator and move it into the board startup code.
> 
> This way we would likely end up in cleaner configurator scripts and more
> flexible configurations for the end-user. Last but not least it would
> became easy to have only one .conf file that is usable for several
> boards.

The PIO configurations are a mess, overused and abused. But to that time
we didn't have any board specific initialization. As this is available
now, it should be used.

But there are still different requirements and board variations (also
called jumpers ;-)). And not all boards do have a board initialization
right now. As an intermediate solution and for the remaining configs,
which cannot be hard coded, I'd suggest to move all this GPIO
configuration to one single place, instead of spreading it all over the
configuration tree. That would also provide a good overview about which
pins are used for what purpose.

But to underline my general general view: Move as much as possible to
the board init file.

Regards,

Harald