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

Ole Reinhardt ole.reinhardt at embedded-it.de
Thu Oct 11 17:53:36 CEST 2012

Hi all,

I'd like to share some thoughts about I/O pin configuration on CPUs that
support to map the I/O signals of a peripheral to different I/O ports:

Until now we mostly used one of the following two ways to configure the
I/O pins of a peripheral:

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

Samples: UARTs, EMAC drivers etc.

Mostly the I/O pins are configured somewhere in the driver init function
that is called by NutRegisterDevice()

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

So I'm thinking about a better way to do the configuration.

Sorry for taking the linux example again:

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.

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.

In other words:

I would prefer to leave the I/O pin configuration up to the user and it
should be done in the board init file.

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

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

I'd like to hear your comments




Thermotemp GmbH, Embedded-IT

Embedded Hard-/ Software and Open Source Development, 
Integration and Consulting


Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen - 
tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97

Hauptsitz - Hademarscher Weg 7 - 13503 Berlin
Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002
Geschäftsführer: Jörg Friedrichs, Ole Reinhardt
Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 

More information about the En-Nut-Discussion mailing list