[En-Nut-Discussion] FRC: Direct or Pointer

[Ulrich Prinz]

Sorry but I had to break that discussion.

Here is the new headline.


>> Nevertheless, I stumbled over one inconsistency.
>>
>>> 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)

That's another benefit. With macros you could set any value any time and
you can address the wrong register and search hours for the problem
without finding it. With the pointer structs you first will wonder why
the register is not presented by the prediction system of your editor
and as e second barrier you get a compiler error that this register
doesn't exist in this struct.
>
>> 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.
>
This is not a reason to go back, but to switch between differnet include
files... for my humble opinion.

> 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.
>
What is the difference between the predefined files you get from a chips
manufacturer, whether it is direct or pointer? If it has errors it has
errors...

If they renamed some bits, even they have the same functionality, you
have to correct it, direct or pointer. I know, it's hard and its hell of
work, but it needs to be done.

Best regards
Ulrich