[En-Nut-Discussion] Unified GPIO implementation

[Ulrich Prinz]

Oh, now it gets difficult for me to maintain the branches :)

Now I have to cross update 4? 5?...

Ok, I'll already announced our companies internal branch to go obsolete 
in a few days. All Nut/OS tweaks will pass by me and are integrated into 
sourceforge trunk.

Then I already finished CortexM3 clock/PLL setup, I will merge it 
tomorrow. I rewrote most of it and moved it out of system_stm32f10x.* to 
stm32_clk.*. We now have fully flexible and automatic clock and PLL 
setup via nutconf.

Then I need to dive right into EMAC/PHY. Already planning for it.
After that we merge CortexM3 to trunk.
If you can get the GPIO system working in the meanwhile I will go this way:
ugpio->trunk->devnut_m3n->trunk

Best regards
Ulrich

Am 25.10.2010 19:59, schrieb Thiago A. Corrêa:
> Hi,
>
>
>      I've just created a branch ugpio (unified gpio) to commit changes
> related to the Wiki specs.
>      Already added the mandatory and optional constants with some
> sensible defaults to include/dev/gpio.h
>      Having defaults in gpio.h also lets us keep the Doxygen tags in
> just one file.
>
> Kind Regards,
>     Thiago A. Correa
>
>
> On Wed, Oct 20, 2010 at 6:23 AM,<uprinz2 at netscape.net>  wrote:
>> Hi!
>>
>>
>> I fully agree. STM32 does support PullDown too for inputs.
>>
>>
>> I'll check the wiki and update it.
>>
>>
>> Best regards
>> Ulrich
>>
>>
>> -----Original Message-----
>> From: Thiago A. Corrêa<thiago.correa at gmail.com>
>> To: Ethernut User Chat (English)<en-nut-discussion at egnite.de>
>> Sent: Wed, Oct 20, 2010 4:46 am
>> Subject: Re: [En-Nut-Discussion] Unified GPIO implementation
>>
>>
>> Hi All,
>>
>> About the wiki article, in the part it says:
>>
>> The obsolete definitions:
>>
>> #define GPIO_CFG_MULTIDRIVE  Enable Open-Drain: This should default as
>> PushPull can break the chip if enabled by accident.
>>
>> It is dangerous to have PushPull as default with GPIO_CFG_OUTPUT. If
>> one uses the examples with a slightly different board it might kill
>> the hardware. So default should be Open-Drain or Weak Pullup if the
>> CPU supports that. If PushPull is supported it must be set by reason
>> and under programmers control.
>>
>> ---
>>
>> Actually, I think the PushPull is the one that is not available on
>> most platforms. AVR32 and AVR 8 bits both have weak pull ups refered
>> as simply pull up, and in the case of AVR32 there is a open-drain
>> enable register.
>>
>> I think we should then have a definition where PushPull must always be
>> explicitly enabled, never default. And output should be open-drain if
>> the CPU supports that. Therefore remove the "Weak pullup" case from
>> the specification, as it's simply GPIO_CFG_PULLUP and it's dealt with
>> as a flag of it's own if the user wants it enabled.
>>
>> Based on that, I'm making the changes as this:
>>
>>     if (flags&  GPIO_CFG_OUTPUT) {
>>         gpio_port->oders = mask;
>>         /* Unless specified, outputs default open-drain in Nut/OS */
>>         if(flags&  ~GPIO_CFG_PULLUP)
>>             gpio_port->odmers = mask;
>>         else
>>             gpio_port->odmerc = mask;
>>     } else {
>>         gpio_port->oderc = mask;
>>     }
>>
>> ODMER is the register to enable Open Drain mode in AVR32.
>>
>> Also, if you assume that PushPull is the special case, than this part
>> should also be modified:
>>
>> #define GPIO_CFG_PUSHPULL    AVR: Enable Pullup, ARM/Cortex: Enable
>> strong pull-up.
>> #define GPIO_CFG_PULLUP      Enable Pullup.
>>
>>
>> to
>>
>> #define GPIO_CFG_PULLUP        Enable (weak) Pullup, (AVR, AVR32, ARM/Cortex).
>> #define GPIO_CFG_PUSHPULL    Enable strong pull-up if available (ex.
>> ARM/Cortex), otherwise it's just #define GPIO_CFG_PUSHPULL
>> GPIO_CFG_PULLUP
>>
>> One other thing, we might need an GPIO_CFG_PULLDOWN as well. Looks
>> like there are AVR32 parts with this feature judging from the Atmel
>> Software Framework source code in the repository.
>>
>> Kind Regards,
>>      Thiago A. Correa
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>
>>
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion