[En-Nut-Discussion] Where to define PIN mapping
harald.kipp at egnite.de
Tue Feb 19 12:38:08 CET 2013
On 18.02.2013 13:01, Uwe Bonnes wrote:
> most recent controller allow to select the pin location for internal
> devices. So ethernut needs a way to know about the pin setting. Pin Setting
I'm not sure if I got you. Even early AT91 devices allow to have certain
device at alternate pins, this is nothing new.
The board.conf files are responsible to define the pins actually used on
a specific board layout.
Some board may be designed more flexible, providing jumpers or
connectors to allow the user to configure alternatives. In that case the
user needs to reconfigure the pins in the Configurator. But in most
cases the board.conf file already contains a required definitions for
> can be announced to the driver in two ways:
> - at compile time with #defines
> - at run time with a driver control block(dcb)
> While e.g. the dcb solution for a I2C bus with two(SDA/SCK) or three pins
> (SMB)pin is most flexible, for a full fledged uart solution with RX, Tx and
> all the controll lines the dcb get tedious and will use some or maybe on a
> AVR lot of RAM.
IMHO, there are two general types of drivers, pre-configured and
self-adapting. Nut/OS preferably uses pre-configured layouts, which
requires individual binaries for each target. Linux drivers are
self-adapting, where the same binary works on all targets.
> Furthermore when the pin setup is done with defines, pin setup can be made
> in the configurator, as most stm32 drivers do or in the board.h file.
The intention of board.h is to allow to write one application source
file, that runs on several targets. Most user applications will be done
for a specific target. They do not need board.h at all.
Drivers should not refer to board.h, because it is hard coded for the
supported boards. Drivers should be kept configurable. At egnite, we do
have several boards, which we never published. I do not want to be
forced to adapt board.h to each new board design. Right now I only need
to create board.conf for each board, without changing any source code file.
> Is there some policy or consense what solution to choose?
Again, I'm not sure if I really got what you meant. Please correct me,
if I misunderstood the point.
More information about the En-Nut-Discussion