[En-Nut-Discussion] Nut/OS GPIO API Initial Design and Current Status

[Ulrich Prinz]

Aah, what?

Am 15.10.2012 10:48, schrieb Harald Kipp:
> Hi Ulrich,
>
> On 14.10.2012 23:15, Ulrich Prinz wrote:
>> Am 14.10.2012 13:07, schrieb Harald Kipp:
>>> Which is probably an advantage. But still there is no reason for me to
>>> use this API in AVR-specific drivers.
>>
>> But, if the API is effective and fast, why _not_ using it? Why making
>> porting of the OS difficult? If you take a different chip as a reference
>> to implement your chip, you will need your time to understand why a user
>> carefully developed a fast GPIO driver and then is not using it...
>
> If I want to implement a new AVR driver for Nut/OS, I'll be familiar
> with avr-libc. And I can re-use existing code that uses avr-libc
> functions. If I run into problems, I can ask the AVR community and
> present my avr-libc based code, that all other AVR developers can follow.
>
But it is very new to me that GPIO access functions are (new-)libc...

If you like to use AVR it is always a good idea to ask the AVR community 
and if you like to use Nut/OS you should join this list. If you like to 
use Nut/OS on AVR you might like to do both.

> If I want to implement this driver to a new target, I'd not take the low
> level AVR functions for reference. Instead, I'll study documents and
> samples of the new target to see, how this is typically implemented.
>
Now I don't takt the function itself but the functions name and 
parameters and, as far ass it works, the parameters names.

> Remember the USART driver? The AVR code had been taken as a reference
> for the AT91 instead of creating an AT91 specific solution. As a result,
> this driver contains a lot of duplicate code, which made sense on the
> AVR, but looks quite funny on the ARM.

I think that API programmers are thinking different than driver 
programmers. And driver programmers have to think different than API 
programmers without to forget that they program for API users.

Or:
If you are a driver programmer try fast and efficient code but keep in 
mind who is using your code.

In Nut/OS kiddies like to use it for AVR and if they grow up and study 
they might run into projects using ARM. So why learning Nut/OS from 
scratch again? Why shouldn't a basic NutGpioPinConfigSet( PORT4, PIN5, 
PINCFG_OUTPUT | PINCFG_PULLUP) work for a first step? It worked in AVR 
too...

Adding a define for PULLUP while knowing that there are more specific 
PULLUP10K, ..47K, ..100K version for this special ARM available doesn't 
hurt nobody

Look at the I2C:
Using the old routines in STM32 works and you can even select if these 
routines should address I2C-Bus0 or Bus1. It was just a #define to 
establish this. No code overhead, no footprint in Flash, nor footprint 
in RAM, just four lines of #define surrounded by an #ifdef #else #endif.

Ulrich