[Top][All Lists]
[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
- [avr-gcc-list] possible compiler bug?, Brian Dean, 2002/08/31
- Re: [avr-gcc-list] possible compiler bug?, Theodore A. Roth, 2002/08/31
- Re: [avr-gcc-list] possible compiler bug?, Brian Dean, 2002/08/31
- Re: [avr-gcc-list] possible compiler bug?, Theodore A. Roth, 2002/08/31
- Re: [avr-gcc-list] possible compiler bug?, Brian Dean, 2002/08/31
- Re: [avr-gcc-list] possible compiler bug?, Theodore A. Roth, 2002/08/31
- Re: [avr-gcc-list] possible compiler bug?, Brian Dean, 2002/08/31
- Re: [avr-gcc-list] possible compiler bug?, Joerg Wunsch, 2002/08/31
- Re: [avr-gcc-list] possible compiler bug?, Brian Dean, 2002/08/31