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

[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.

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.

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.

Regards,

Harald