Re: [avr-libc-dev] [bug #5799] error(?) in iom162.h

[Theodore A. Roth]

On Fri, 17 Oct 2003 address@hidden wrote:


> =================== BUG #5799: FULL BUG SNAPSHOT ===================
>
>
> Submitted by: None                    Project: AVR C Runtime Library
> Submitted on: Tue 10/07/03 at 23:58
> Category:  Header                     Severity:  5 - Major
> Bug Group:  None                      Resolution:  None
> Assigned to:  troth                   Originator Email:  address@hidden
> Status:  Open
>
> Summary:  error(?) in iom162.h
>
> Original Submission:
>
> In definitions for UCSR0A: bit 2 is defined as PE0, this should be
> UPE0. In definitions for UCSR1A: bit 2 is defined as PE1, this
> should be UPE1. This according to datasheet for Atmega162(V) rev:
> 2513E-AVR-09/03
>
> I guess this is the reson why PORTE bits are defined as PORTE0,
> PORTE1.... instead of PE0, PE1.. as would be normal.
>
> I am usign WinAVR-20030913
>
> Follow-up Comments
> *******************
>
> -------------------------------------------------------
> Date: Fri 10/17/03 at 10:49         By: troth
>
> The 09/02 version of the datasheet still has UPEn. I see no mention
> of PEn in the UCSRnA register summary. I'm going to simply replace
> PEn with UPEn instead of adding UPEn and making PEn an alias.
>
> Now the PORTE part brings up another issue. The usage is not
> consistant in this header file. All other port pins are defined like
> PAn while PORTE is PORTEn. The datasheet register summary shows them
> all as PORTxn. I'd prefer to just have all the headers use Pxn
> regardless of what the datasheets say, but that doesn't seem to be
> the concensus of the developers.


Argh!! The datasheets aren't even self consistent on this matter. The
register summary's tend to use either Pxn or PORTxn for port pin
names. While all the actual descriptions of the ports use the Pxn
notation and all the example code (at least what I've looked at) uses
the Pxn notation.

I'm strongly leaning toward changing all the headers to use Pxn and
then defining PORTxn in io.h. I think this is really the only safe way
to change the 1.0 branch without breaking anyone's apps as far as the
PORTxn differences go.

Fixing the UPEn problem risks breaking some 1.0 apps due to namespace
polution of PE0, but I don't see an easy way out on that one.

I think the argument for being "bug-for-bug" compatible with the
datasheet is invalidated in this case since the individual datasheets
are not even self consistent.

Ted Roth