[En-Nut-Discussion] Porting means breaking the rules?

[Ulrich Prinz]

Hi!

Am 02.09.2010 19:50, schrieb Thiago A. Corrêa:
> Hi,
>
> On Thu, Sep 2, 2010 at 8:12 AM, Harald Kipp<harald.kipp at egnite.de>  wrote:
>>
>> This makes sense to me. In any case, if anyone is using an exotic board
>> layout, he can always modify existing driver code.
>>
Right!
>>
>
> Could you or Michael commit the changes to a branch? I'm interested in
> taking a look at it.
> He said that he had to keep a 3rd GPIO API to interface with the
> Software Framework. Personally I don't see much value in the SF, as
> it's mostly simple wrapping around registers, with except from the
> USART and Network, both of which are much better implemented in Nut/OS
> than in the SF.
>
I still need to get the basic things running, then I'll check in. (See 
my post one minute ago in this thread, right at the end).
>
>
> I think the Gpio* functions aren't so bad. They are not too different
> from the linux API AFAIK.
> But the macros could perhaps be imprved. They are a bit hard to understand.
>
Yes, there might be two sets of macros:
The sbi()/cbi() will remap to the bit-mirror area of the cortex and will 
enable single cycle instructions.
If I don't forget it, I'll add a tbi() test bit function with single 
cycle too.

Then there are port() functions that can be single cycle too. This even 
works on ARM as there is a register for setting and one for clearing 
every GPIO pin whose bit was set to one.

I'll try to put that on my todo list. If I forget, just feel free to 
modify it after I checked in the first running code.

Best regards
Ulrich