[En-Nut-Discussion] Next Nut/OS 5 release candidate

[Uwe Bonnes]

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

    Harald> Hi Uwe, On 11.10.2012 12:28, Uwe Bonnes wrote:
    >>>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:
    Harald> And the latter causes the following problem (probably on all ARM
    Harald> targets):
    >>  Could you test current svn?

    Harald> r4751 fixed this.

Good

    >> I started a discusssion some time ago about the need for most
    >> GPIO_CFG defines common. I couldn't make my arguments
    >> understandable. Are they more understandable now?

    Harald> What thread are you referring to. This one?

    Harald> http://lists.egnite.de/pipermail/en-nut-discussion/2012-September/013942.html

No. I meant
http://lists.egnite.de/pipermail/en-nut-discussion/2012-July/013712.html

    >> Rethinking the commit, probably in nut/include/dev/gpio.h after all
    >> includes #if !defined(GPIO_CFG_INIT_HIGH) #define GPIO_CFG_INIT_HIGH
    >> 0 #endif
    >> 
    >> #if !defined(GPIO_CFG_INIT_LOW) #define GPIO_CFG_INIT_LOW 0 #endif
    >> 
    >> would have been better. Should I do another commit?


    Harald> No, I'd prefer the current solution. With the one above the
    Harald> individual driver is no longer able to properly adapt to a
    Harald> missing feature, like

    Harald> int FooBarApi(void) { 
    Harald> #ifdef GPIO_CFG_INIT_HIGH /* Normal code. */ 
    Harald> ...  return 0; 
    Harald> #else /* Not supported, return an error. */
    Harald> return -1;
    Harald>  #endif
    Harald>  }

But with  nut/include/dev/gpio.h containing

#define  GPIO_CFG_UNIMPLEMENTED 0

#if !defined(GPIO_CFG_INIT_HIGH)
#define GPIO_CFG_INIT_HIGH GPIO_CFG_UNIMPLEMENTED
#endif

#if !defined(GPIO_CFG_INIT_LOW)
#define GPIO_CFG_INIT_LOW GPIO_CFG_UNIMPLEMENTED
#endif
, your user code above _can_ do
#if (GPIO_CFG_INIT_LOW == GPIO_CFG_UNIMPLEMENTED)
==warn user==
#endif
if the requested feature is essential, but compile will _not_ break if user
code handles the feature as a welcome feature, not a must..

As with time more architectures will implement the feature, the always
needed check in your code above become more and more superfluous...

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

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