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

[Ulrich Prinz]

Guys, do as you like.

Omit improvements, stick to old things, whatever you like...

I had a release phase just behind me and that was pure stress.
I'll take a time off, I think.

Ulrich

2012/10/18 Uwe Bonnes <bon at elektron.ikp.physik.tu-darmstadt.de>:
>>>>>> "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 ----------
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion