[En-Nut-Discussion] Unified GPIO implementation

[Ulrich Prinz]

Hi Thiago!

Am 01.11.2010 20:55, schrieb Thiago A. Corrêa:
> Hi,
>
>
> On Tue, Oct 26, 2010 at 7:00 PM, Ulrich Prinz<uprinz2 at netscape.net>  wrote:
>> Now I think of how to go best way. Harald told me how to use the
>> master-script to build all platforms and check if the compile is successful.
>> Then I could merge to trunk.
>
> How do you use the master-script? Did it work? :)

Didn't check for now as I have to install AVR32-GCC too and my 
priorities actually shift according the needs of the company. The 
ethernet stack rised in prio while CANopen and sensors are working. So I 
have to wait a bit for the GPIO.
>
>> On the other hand, I can upgrade USARTs and uGPIO and then do the merge
>> thing. I think USART ans uGPIO is important so let me finish my PHY
>> abstraction and may be send one packet over the STM32 EMAC. Then uGPIO,
>> USART and merge to trunk.
>
> We can merge uGPIO then work on usart on a separate branch just for it.

I think if we cannot synchronize this would be the best. So you can 
continue from GPIO to USART and I can catch up later.
>
>> Ah, if we finished uGPIO, can we do a collection of LEDs? It is so
>> helpfull to simply have a blinking LED and Nut/OS unifies USARTs, SPI,
>> EMACs for all the supported Boards, but the LEDs and push buttons are
>> missing.
>
> I think we have something about leds and push buttons already. This
> last one from you if I remember correctly :)
>
Hehe, yes the drivers are from me but what I meant was to declare the 
existing Keys/LEDs on the *.con file supported boards in the board.h
Let the LEDs blink to show every beginner that at least this is working.

> Anyway, the uGPIO in the branch should work, and I've optimized the
> avr32 part of it a little bit.
> I haven't implemented the tin wrapper macros suggested, but all the
> required functions and constants should be there.
> If we can define the macro interface/requirements, I could start
> working on them.
>
Ah, if you got the idea right, no real function for GpioPinSetHigh/Low 
or GpioPortSet(High/Low) is needed anymore. It just works with #defines.

> We could also consider inline functions instead of macros. Would it be
> a problem to require c99?

Nope, if you keep it as it is needed:

For STM32
#define NUTGPIO_PORTA	GPIOA

#define GpioPinSetHigh( b, p) b->BSRR = _BV(p)
#define GpioPinSetLow( b, p) b->BRR = _BV(p)
#define GpioPinGet(b, p) (b->IDR&_BV(p))?1:0

for ARM it should work similar by adding PORTn_BASE+REG_OFS. But it may 
require some *(volatile uint32_t*) casting.

This should even work for AVR if we can fetch the address of the pretty 
sprayed registers of the ports.

I don't see any C99 for this. No abstract arguments.

Best regards
Ulrich