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: Brian Dean
Subject: Re: [avr-gcc-list] possible compiler bug?
Date: Wed, 28 Aug 2002 19:00:38 -0400
User-agent: Mutt/1.4i

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.

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.

> The solution is to write your own functions / macros that handle both 
> read and write access to these particular registers, to handle 
> writing in the correct order (high, then low) and reading in the 
> correct order (low, then high).

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
-- 
Brian Dean                                      address@hidden
avr-gcc-list at http://avr1.org



reply via email to

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