[En-Nut-Discussion] Extending device structures, was Re: Problem with STM32 pin ...

[Uwe Bonnes]

>>>>> "Ole" == Ole Reinhardt <ole.reinhardt at embedded-it.de> writes:

    >> B.t.w. I in spibus.h, don't see a place to store private hardware
    >> data like in i2cbus.h: /*! \brief Private data of the hardware
    >> specific implementation. */ void *bus_icb;

    Ole> Indeed, the interface control block is missing there. I'd suggest
    Ole> to add a bus_dcb _and_ bus_icb at the end of NUTSPIBUS, and add a
    Ole> node_icb at the end of NUTSPINODE.

    Ole> This way we should be fairly flexible in our implementation.

    >> Do I miss something? Otherwise, can we extend struct _NUTSPIBUS for
    >> void *bus_icb; at the end, without causing damage to others?

    Ole> The above changes should not cause damage to others, but I'd like
    Ole> to suggest to apply these changes to _all_ spi bus drivers, not
    Ole> only to our stm32_spi driver and initialise them with NULL, where
    Ole> not needed.

For structure initialization, is there anything against initializing like

NUTDEVICE devStm32Lcd16Seg = {
    .dev_name = {'1','6', 'S', 'E', 'G', 0, 0, 0},
    .dev_type = IFTYP_CHAR,
    .dev_init = Stm32Lcd16SegInit,
    .dev_ioctl = Stm32Lcd16SegIOCtl,
    .dev_write = Stm32Lcd16SegWrite,
    .dev_open  = Stm32Lcd16SegOpen,
    .dev_close = Stm32Lcd16SegClose
};
versus the old way:

NUTI2C_BUS i2cBus2Stm32 = {
    &i2c2cb,    /* bus_icb */
    I2cBusInit, /* bus_init */
    I2cBusConf, /* bus_configure */
    I2cBusProbe,/* bus_probe */
    I2cBusTran, /* bus_transceive */
    100,        /* bus_timeout */
    0,          /* bus_rate */
    0,          /* bus_flags */
    NULL        /* bus_mutex */
};

With dot-initialization, we don't need to explicitly write NULL or 0 for the
structure elements we don't need, and it is self documenting. The ordered
initialization however needs us to write NULL/0 entries and to write
comments for documentation that can get easy out of sync.

Is there any compiler we still care for that does not support the
dot-initialization for stuctures?

Harald, any comments on extending structures and structure initialization?

Bye
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------