[En-Nut-Discussion] More GPIO discussiob, was RFA_2: Nut/OS GPIO API

[Uwe Bonnes]

>>>>> "Ulrich" == Ulrich Prinz <ulrich.prinz at googlemail.com> writes:

...

    Ulrich> Sorry, but this an absolute no-go! A Pin may never be configured
    Ulrich> as push-pull output without extra user intervention. So _OUTPUT
    Ulrich> ever only sets open-collector mode!  The only way to set
    Ulrich> Push-Pull ist to set _OUTPUT | _PUSHPULL (or_PP if you like)
    Ulrich> Again: The risk of killing something if outputs are wired
    Ulrich> against outputs and then setting one of them as pushpull is
    Ulrich> high. People should think twice if pushpull is needed, so they
    Ulrich> should write two words for the configuration too.

Ulrich, how many CPU did you actual kill by shorting a Pin to Ground? And
how many in some other way?
How many actual Pin driver of actual Mikrocontroller designs die when a
resonable number of pins is shorted to ground for a reasonable time?
And you don't catch the error with shorting VCC to a MULTIDRIVE pin driving
low...

And if we require to use _OUTPUT | _PUSHPULL, how many mail exchanges do you
expect on the mailing list with astonished users reporting that their LED
doesn' light up. And step by step we find out that the LED is ground
connected and the PUSHPULL is missing in the pin configuartion.

But if you sleep better if we change to _PUSHPULL, and if you promise to
watch the mailing list for that users hitting that collision with "minimal
surprise", do a changed RFA, and i won't reject and I will help to clean up
all existing code for Push-pull use without _PUSHPULL;

    Ulrich> Next topic is the naming: MULTIDRIVE is not an exact name. Any
    Ulrich> open-source/open-collector bus is capable of multiple masters
    Ulrich> driving the bus. What we try to tell is, that the pin is of high
    Ulrich> impedance in that case, so not driving high, nor low. This is
    Ulrich> _HIGHZ (high impedance) Please delete _MULTIDRIVE it is
    Ulrich> misleading.

No, it's no misnamed. There are four use cases for a GPIO output:
- drive fast external input. Push Pull is needed.
- drive a ground connected load, like a LED. Push Pull is needed.
- casual drive  a line with pull-ups, alternative with other partners, like
in the one-or-two wire case, _MULTIDRIVE is needed.
- read and write an external device alike a FT245 on non-bus pins (e.g. a
STM100 with less then 100 Pins). Pull-Pull in conjunction with Drive and
release is needed.

In an ideal world, we wouldn't need the construction needed by my RFA to do
a low pulse on a multidrive line: set low, drive, release, set high.
However this allows us to cope with artefacts in our platform
portfolio:
- For AVR you need to "emulate" Multidrive by setting the port high and
switching direction. "set high" and "set low" otherwise would need to be
handled different if pin configuration is Output or Multidrive.
But no port register is available to remember the configuration. So we
would need some port related structure to remember that setting and extra
run time code.

And we need the release/drive commands in all cases if we want fast
switching for read and write from external devices.

To make a long sory short, we could always "emulate" the _MULTIDRIVE
configuration with the combination of "relase and set high" and "set low
and drive and disallow _MULTIDRIVE as configuration option in portable
code. I am unsure about what way is clearer. So again,if you feel easier, do
a changed RFA with that regard. 

...

Bye

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

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