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

Ulrich Prinz ulrich.prinz at googlemail.com
Mon Oct 15 20:25:04 CEST 2012

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.

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 

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.


More information about the En-Nut-Discussion mailing list