[En-Nut-Discussion] Hardware Register Access Using Volatile Pointer
harald.kipp at egnite.de
Tue Apr 26 14:55:28 CEST 2011
On 4/26/2011 1:00 PM, Bernd Walter wrote:
> On Tue, Apr 26, 2011 at 09:27:50AM +0200, Harald Kipp wrote:
>> On 4/25/2011 10:45 PM, Bernd Walter wrote:
>>> On Mon, Apr 25, 2011 at 07:51:25PM +0200, Harald Kipp wrote:
>>>> #define inr(_reg) (*((volatile unsigned int *)(_reg)))
>>> typedef volatile unsigned int AT91_REG;// Hardware register definition typedef struct
> In the end I think it's just a different style with different pros and
Definitely there are no pros for using the "Atmel style", except
> I personally use the Atmel style in my own projects,
> which sometimes
> is tricky since there are name clashings with ethernut includes.
This is even tricky within Nut/OS. Following the good old style of
avr-libc, we try to use port and bit names from the datasheet. This
helps to remember the names. The bad thing is that Atmel datasheets are
not written with C programming in mind.
> A (compiler) memory barrier isn't just writing imode - it also writes
> other registers, which are unrelated.
That's the other side of the coin.
> It's only the programmer who knows wether a barrier or volatile variable
> is the better option.
My view differs. If the programmer knows better, than he better use
memory barriers instead of volatiles. Simple reason: There are cases,
where the order of I/O register reading and writing is not important at
all. Why not let the compiler decide and only use memory barriers where
>> That's the point. I assume too, that the suggested approach will remove
>> inr(). Further, I'm not sure, that an access to volatile memory will be
>> kept, if the result is not used in the code. I wasn't able to find any
>> document on this either.
> Yes - but with defining it volatile the compiler can't know that reading
> won't change anything - as it surely does for reading hardware registers.
> It is free to remove the dummy variable itself, which I think is a good
That's your opinion. You may call me an awkward doubter, but again my
question: Is this documented anywhere? Are you sure that the compiler is
aware, that a read may effect the source?
What I understood is, that volatile means for reading, that the compiler
must reload the value each time before using it. I can't find any
document that states, that the read is done in any case, even if the
result is not needed.
A few tests with GCC 4.6 showed, that the read is conserved. But is that
More information about the En-Nut-Discussion