avr-libc-dev
[Top][All Lists]
Advanced

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

Re: [avr-libc-dev] AT90CAN128 - Flaming On


From: Theodore A. Roth
Subject: Re: [avr-libc-dev] AT90CAN128 - Flaming On
Date: Thu, 13 May 2004 16:09:55 -0700 (PDT)

On Thu, 13 May 2004, Bruce Graham wrote:

> All,
>
> I hope nobody imagines that I am picking on them.  This is a truly
> marvelous thing you have here.
>
> We strive to continuously improve the product, and to that end.
>
> The header file iocan128.h has the following additional problems:
>
> Currently bits 3, 2, 1, 0 in register XMCRA seem to have an extra letter
> 'L' in their names.  According to    4250C-CAN-03/04 those lines should
> be corrected read:
>
>     #define    SRW11    3
>     #define    SRW10    2
>     #define    SRW01    1
>     #define    SRW00    0
>
> In the bit definitions for the Timer/Counter 2 Control register, the
> name in the comment is TCCR2.  It should be TCCR2A.
> Bit 7 in the Timer/Counter 2 Control Register should be FOC2A
> Bit 5 in the Timer/Counter 2 Control Register should be COM2A1
> Bit 4 in the Timer/Counter 2 Control Register should be COM2A0
>
> The ordering of the register bit definitions follows no plan or outline
> I can determine, and the definitions for the PINA are located with the
> definition of the register(!?).  The register bit definitions should
> probably be rearranged in some sensible order, by register address, or
> alphabetic, or by functional group.

I haven't found it to be sensible myself, so you're not alone.

I've found that it makes the headers much easier to verify if the the
bit defs immediately follow the register address def. I did this when I
wrote the iotn13.h header a few weeks ago. Eventually, I will go through
and reorder things to match what I did with the tiny13, but that will
take a lot of time that I don't have at the moment.

Alas, I did not originally write the iocan128.h file. I only comitted it
and have fixed things as they have been reported.

>
> Has anyone noticed that the datasheet has a wowser on page 57-58
> indicating that the interrupt vectors are two bytes long when in fact
> they are four bytes long.  Just wondering.

Atmel's datasheets are notorious for having errors in the early
releases. This is very likely a cut/paste problem. They also have a
tendency to rename bits and registers on occasion.

The _VECTORS_SIZE def in the iocan128.h looks to use the four bytes
vector.

>
> Continuing to check
> Bruce

Could you collect all the fixes you find and submit them as a patch?
That is much easier and quicker for me to get into cvs. Generating the
patch is very simple, just do this:

  $ cvs diff -u > foo.diff

Be sure to send the patch as an attachment so you email client doesn't
mangle it during inlining.

---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: address@hidden




reply via email to

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