[En-Nut-Discussion] RFA_2: Nut/OS GPIO API
Ulrich Prinz
ulrich.prinz at googlemail.com
Fri Oct 19 15:18:29 CEST 2012
You'd prefer to build new cars without ABS as old cars don't have it
and ABS cannot be added later on?
Second, how many lines of wrapped around code a single GPIO pin
configuration should need?
GPIO_CFG_OPEN_DRAIN...
NutGpioPinCfg( NUT_GPIO_PORT_ONE, NUT_GPIO_PIN_FOURTEEN,
NUT_GPIO_PIN_CONFIG_AS_INPUT | NUT_GPIO_PIN_CONFIG_WITH_PULLUP_ON...
Couldn't we stick to some short readable thing, couldn't we use
acronyms that are usual even outside of ATMEL and couldn't we define
new acronyms that clean up with old errors that we made?
So let's start using NUTPINCFG_OP or _OUT for output that does use
open-drain. NUTPINCFG_PP for push-pull _HIZ.
Much lesss writing, much less obsolete characters on the screen.
And to keep backwards compatibility, we could do this:
#define GPIO_CFG_OUTPUT (GPIO_CFG_OUT | GPIO_CFG_PP)
#define GPIO_CFG_MULTIDRIVE GPIO_CFG_HIZ
Why always stick to these tiny old and slow AVRs? Several new members
of the list started right into Nut/OS on ARM an CM3 without ever
having seen an AVR.
I mean we like to present an over all new major release of Nut/OS and
then stick to old and obviously wrong decisions we made at times far
in the past.
Sometimes I don't understand...
Ulrich
2012/10/18 Ole Reinhardt <ole.reinhardt at embedded-it.de>:
> Hi Ulrich,
>
>> Sorry, but this an absolute no-go! A Pin may never be configured as
>> push-pull output without extra user intervention. So _OUTPUT ever only
>> sets open-collector mode!
>
> I fully understand your point, but anyway I do not agree to you! This
> would break any existing Nut/OS application as GPIO_CFG_OUTPUT is
> traditionally used in push/pull mode.
>
> Next problem is that several architectures do not support open drain
> mode at all (natively). Most prominent AVR. They default to push/pull
> mode and Nut/OS users are used to this behaviour.
>
>> Next topic is the naming:
>> MULTIDRIVE is not an exact name. Any open-source/open-collector bus is
>> capable of multiple masters driving the bus. What we try to tell is,
>> that the pin is of high impedance in that case, so not driving high, nor
>> low. This is _HIGHZ (high impedance)
>> Please delete _MULTIDRIVE it is misleading.
>
> It seems that there are different views what MULTIDRIVE is. Most vendors
> define MULTIDRIVE as "Open drain". So I decided to rename the flag as
> GPIO_CFG_OPEN_DRAIN in my proposal.
>
>
> Bye,
>
> Ole
>
> --
>
> Thermotemp GmbH, Embedded-IT
>
> Embedded Hard-/ Software and Open Source Development,
> Integration and Consulting
>
> http://www.embedded-it.de
>
> 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