[En-Nut-Discussion] Which is the latest greatest branch

[Thiago A. Corrêa]

Hi,

On Sat, Oct 29, 2011 at 8:14 AM, Harald Kipp <harald.kipp at egnite.de> wrote:
> Hi Ulrich,
>
> In contrast to the Linux project, I do not want to be the guy who
> incarnates the final authority. The advantage of a small project like
> Nut/OS is, that it is able to cope with democracy. ;-)
>
>
> On 28.10.2011 23:19, Ulrich Prinz wrote:
>> On 28.10.2011 06:19, Henrik Maier wrote:
>>> arch/arm                  [generic ARM stuff like context.c]
>>> arch/arm/at91       [stuff for all AT91 devices]
>>> arch/arm/at91/sam9  [specific to this series]
>>> arch/arm/at91/sam7
>>> ...
>
> I'm still not convinced, that this is the best long term solution. But I
> see the point and try to be realistic. My priority is, to reduce porting
> effort and maintenance to a minimum number of files for all platforms.
> On the other hand, Nut/OS is mainly driven by developers, who need a
> working solution for a specific product. These developers, including me,
> are always under deadline pressure. They simply do not have the time to
> adapt a solution to all platforms.
>
> So, finally yes, let's move forward in the direction that Henrik proposed.

I agree with Harald's goals to keep duplicate code to a minimum and
support features drivers on all platforms. I can see duplicate code
drifting from AVR to ARM and AVR32. Those will just get harder to
merge.

>
>
> === OFF TOPIC ===
>
> Nevertheless, I stumbled over one inconsistency.
>
>> I agree, that we should look at those who did that job for a long time
>> now before we try to develop something on our own. And yes, the linux
>> structures look pretty fine to me.
>
> Just the fact that Linux uses it, seems to sanctify everything these
> days. But wait....

Well, I guess it's far from it, but on the other hand they have to
support a large number of SoCs in their tree, so there is some
previous experience we could learn from.

>> ATMEL works with absolute register addresses while Cortex (and the whole
>> rest of the world) works with pointers to struct that represents a set
>> of registers.
>
> Now what? As far as I know, Linux doesn't use structure pointers to
> access registers.

Yeah, it doesn't for all platforms I've seen (AVR32 and Samsung ARMs).
It does more or less what we do, but they do exploit inline functions
a lot more than we do, and it makes the code better (more type safe
than macros)

> Btw., your statement about Atmel isn't fully correct. For specific
> reasons, avr-libc, not Atmel, uses absolute addresses. Atmel started to
> use structure pointers, when introducing the first ARM cores. Nut/OS for
> ARM, not Atmel, continued to use preprocessor macros for the AT91 family.

I'd like to point out that I'm being forced to go back to registers
addresses after using Atmel's structs defined by the headers in the
toolchain, because they are not compatible between different chips in
the AVR32 family. I'm porting Nut/OS to UC3L064 and some of the
structs are not the same. Heck even their defines in some cases are
not the same, like the PIN definition and function selection.

There is a big advantage in using a set of access helpers defined by
toolchain or framework to access registers or interface with
subsystems, but sometimes they are faulty and non-portable, and that
is a no-no to me.

Kind Regards,
    Thiago A. Correa