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

[Thiago A. Corrêa]

Hi,

On Mon, Oct 31, 2011 at 8:19 AM, Harald Kipp <harald.kipp at egnite.de> wrote:
>
>>>> 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)
>
> In a local branch I'm already using the following new set of functions.
>
[...]
> static inline void mem_wr(unsigned int reg, unsigned int val)
> {
>    *(volatile unsigned int *) reg = val;
> }
>

Doesn't inline in C require c99?
I admit I'm more familiar with C++ regarding the standards.

Anyway, Linux documentations suggest using inlines for optional
features, and let the compiler optimize away empty inlines, but that's
another topic :)

[...]
> Comments are welcome.
>
> There are two reasons for not committing them until now. One problem with static inline is the incompatibility among compilers.
>
> http://www.greenend.org.uk/rjk/2003/03/inline.html
> seems to provide an acceptable solution.
>
> The other reason was the directory structure, which had been discussed in the parent thread.
>
> One problem with structures is, that they are entirely based on volatiles. Compilers are more or less all broken here and it will never get fixed, IMHO.
>
> OK, I can hear you shouting: "But you are using volatiles as well!" Right, _but_ the inline function offers all options, they are most flexible. I _can_ use volatiles, but I _must_ not. Access via structures is convenient for the programmer only. They are difficult to adept to different requirements.
>

I actually like the way the code looks using structs a lot more. It
makes it easier to see what the intentions are, and you can use
operator syntatic suggar like |= and &=
The problem I was facing is that Atmel defined the structs in UC3A and
B families and they in a different code incompatible way in the L
family. The previous definition just had the registers in the struct,
plain and simple, but the L family has a union between other structs
to map the optional USART modes, like SPI mode, etc.
Then, instead of struct.register the code requires
struct.union.register in order to keep using their struct definitions.

I don't mind going back to structs even if it means I have to recreate
them myself and add some usart_regs.h file somewhere inside
arch/avr32. I'm just not too sure what is the safest way to keep the
code "future-compatible".
Linux does keep their own register definition includes instead of
relying on compiler/manufacturer files. Maybe that's the solution here
indeed.

Also, using structs has allowed Ulrich to make the code a lot smaller
if I recall an older email. So this is a nice plus to that.

Kind Regards,
    Thiago A. Correa