avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] possible compiler bug?


From: E. Weddington
Subject: Re: [avr-gcc-list] possible compiler bug?
Date: Wed, 28 Aug 2002 17:35:29 -0600

On 28 Aug 2002 at 19:00, Brian Dean wrote:

> On Wed, Aug 28, 2002 at 03:38:19PM -0600, E. Weddington wrote:
> 
> > This is not a bug.
> 
> I disagree.
> 
> > Note that not all 16-bit accesses require this method. See in the
> > datasheet: 16-bit Timer/Counter ...> Accessing 16 bit Registers.
> 
> So in the cases where it doesn't matter what the order of access is,
> writing the high byte first is equivalent to writing the low byte
> first.  This, I know.
> 
> > This applies to the 16-bit Timer/Counter registers which are the (at
> > least for the ATmega128) TCNTn, OCRnA/B/C, ICRn registers.
> > 
> > The datasheet says: "To do a 16-bit write, the high byte must be
> > written before the low byte. To do a 16-bit read, the low byte must
> > be read before the high byte."
> 
> Yes, that is what I'm saying.
> 
> > The paragraph before that says: "Not all 16-bit accesses use the
> > Temporary Register for the high byte. Reading the OCRnA/B/C 16-bit
> > registers does not involve using the Temporary Register.
> 
> So if all 16 bit I/O ports consistantly require the high byte to be
> written first, followed by the low byte, then shouldn't the compiler
> be fixed to do this in all cases?  In cases where it doesn't matter,
> then it won't hurt.  But in cases where it does matter, then at least
> correct code will be generated.
> 

That's the crux. It's not all 16-bit I/O ports. This just has to do 
with the Timer/Counter registers where it's important to read/write 
coherent 16-bit values over an 8-bit bus.

Another reason for rolling your own functions is that if you read 
further down in the section, Accessing 16-bit Registers, in the 
datasheet, it says that if you are in the middle of reading/writing 
one of these 16-bit registers, and an interrupt happens where the 
interrupt will also access ANY of those 16-bit registers that shares 
the Temporary Register, then there will be a mighty clash at the 
Temporary Register and it screw up the values royally. So, when 
rolling your own functions, add a disable interrupts and enable 
interrupts bookends around the operation.


> It would be a shame to have to write special functions to handle this
> very commonly used access to memory mapped I/O ports, when the
> compiler should be generating the correct code sequences.
> 
<snip>
> 
> Yes, like I mentioned in my first message, that's what I did to solve
> the problem.  But I think the real solution is to change the code
> generation in the compiler so that this hack is unnecessary.
> 
> -Brian

A slight misperception about the GCC compiler. The GCC compiler 
compiles for multiple different targets. It's near impossible for GCC 
to cover all these "special cases" for all the varieties of 
architectures.

And this is not necessarily a hack. The datasheet is very explicit in 
what is required to access these registers. If anything, blame Atmel 
for creating an issue to hack around.

But this might be a suggestion to add to the AVR standard library 
(avr libc).

Eric

avr-gcc-list at http://avr1.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]