[En-Nut-Discussion] Bit banging drivers broken?

[Uwe Bonnes]

>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:

    Harald> Hello Uwe, r4683 changed

    Harald>  #undef GPIO_ID #define GPIO_ID MMC_CLK_PIO_ID #include
    Harald> <cfg/arch/porttran.h> static INLINE void MMC_CLK_LO(void) {
    Harald> GPIO_SET_LO(MMC_CLK_PIO_BIT); }

    Harald> to

    Harald>  static INLINE void MMC_CLK_LO(void) { GpioPinSetLow
    Harald> (MMC_CLK_PIO_ID, MMC_CLK_PIO_BIT); }

    Harald> That doesn't look correct to me, because according to
    Harald> conf/dev/dev.nut MMC_CLK_PIO_ID is

    Harald>  "Port ID of the clock line."

    Harald> not the port address. I think this had been done to support

    Harald>  SbiMmcIfcInit()

    Harald> which requires the ID to enable the PIO clock in PMC_PCER.

With an implemented NutGpio Api for that architecture, we wouldn't need the
clock argument as NutGpioPinConfigf would care.

    Harald> I think the same problem exists for dev/jtag_gpio0.c, where

    Harald> #define JTAG0_TDO_PIO_ID PIO_ID

    Harald> is defined in include/arch/arm/board/ethernut3.h and then used
    Harald> in dev/jtag_gpio0.c

    Harald> static INLINE int JTAG0_TDO_IS_ON(void) { return
    Harald> GpioPinGet(JTAG0_TDO_PIO_ID, JTAG0_TDO_PIO_BIT); }

    Harald> finally translated to

    Harald> inr(PIO_ID + PIO_PDSR_OFF) & _BV(bit) ? 1 : 0

    Harald> in include/dev/gpio_at91.h. For the AT91X40

    Harald> #define PIO_ID 8 #define PIO_PDSR_OFF 0x0000003C

    Harald> I'm not sure about the AVR32 and the Freescale branch.

Okay, you got me. I cared for AVR and STM, but not the rest. How to proceed?
I think the NutGpio Api has clear advantage so reverting would be a step
back. And adding #if isn't appelling too. But I don't feel like I can
complete the NutGpio functions for all architecture. So perhaps split off
the old file before my change with a similar name, but some addition to mark
it as transitory. Architectures with incomplete NutGpio Api should reference
the old file, but the new file when NutGpio is fixed. However this will
cause problems with architecture independant examples. Or perhaps some
header could define something to mark NutGpio incomplete for these
architecture and the example could evaluate.

Is that okay?

Bye

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

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