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

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

[avr-libc-dev] Re: Iotn13.h


From: Bruce Graham
Subject: [avr-libc-dev] Re: Iotn13.h
Date: Fri, 21 May 2004 16:07:29 -0400

Ted,

Thanks this will be most helpful.

Bruce

"Theodore A. Roth" wrote:

> On Thu, 20 May 2004, Bruce Graham wrote:
>
> > Ted,
> >
> > Here is my suggested patch for the header iotn13.h  I did not test it
> > very well since I have been unable to run "avr-as" by itself
> > successfully.  I seem to be short the right document, which I probably
> > have but can't find, or less likely don't have and can't find.
> >
> > Some things may be controversial:
> > (1) When there is no External Memory -- should XRAMEND be 0? or should
> > it be equal to RAMEND.  Actually I could go either way and I can't see
> > where the symbol is used -- probably in malloc.
> > (2) Although PB5 is a handy shorthand, the tradition for bit names seems
> > to be:
> >     (a) use the data sheet name if a name is given
> >     (b) concatenate numbers to the register name if a name is not given
> > (3) I was not sure what SPEN referred to in register SPMCSR.  I could
> > not find it in the data sheet, nor could I find it in one or two other
> > data sheets I checked.  I hope it was just a mistake, but I could
> > believe it came form an earlier version of the family.
>
> Attached is what I committed (basically limited to comments only, but
> with the fix for SPMEN).
>
> A few notes about your original patch.
>
>   - Please don't add lots of white space at the end of comments.
>   - EEAR and EEARH don't need to be undef'd since they are handled by
>     avr/io.h.
>   - SP and SPL don't need to be undef'd either.
>
> Now, I like the concept you introduced for setting _VECTORS_SIZE, but I
> didn't include that change here since it should be done more globally. I
> would rather see something like the following.
>
> In avr/io.h:
>
>   /* The value defined in the device io header for _MAX_VECTOR_NUMBER
>      should be the highest number used in the SIG_* defines, while
>      the value for _VECTOR_INSN_SIZE should be the size of the vector
>      instruction in bytes. This will be either 2 (for devices that don't
>      support the JMP instruction) or 4 (for devices that can use the JMP
>      instruction). */
>   #define _VECTORS_SIZE ((_MAX_VECTOR_NUMBER)+1)*_VECTOR_INSN_SIZE
>
> Then in each io*.h file (using iotn13.h as example):
>
>   #define _MAX_VECTOR_NUMBER  9
>   #define _VECTOR_INSN_SIZE   2
>
> One last thing about your usage of CVS. I think you are making it more
> difficult than it needs to be. It looks like you are trying to work with
> a local repository with your own tree structure or a repo for each file
> you are working on. This is making it a bit more difficult for you to
> generate patches and for me to apply those patches.
>
> Here's the steps you need to take to generate a patch (as unix shell
> commands, but it shouldn't be too hard to figure what to do for
> windows).
>
> Check out the cvs tree:
>
>   $ cvs -z3 -d:ext:address@hidden:/cvsroot/avr-libc co avr-libc
>
> Go into the tree:
>
>   $ cd avr-libc
>
> Edit files to your hearts content:
>
>   $ vim include/avr/iotn13.h
>
> When you are done editing, generate a patch:
>
>   $ cvs diff -u > my-changes.diff
>
> Look the diff file over and if it looks right, post it to the
> avr-libc-dev list.
>
> Notice that I generated the diff file from the top of the tree. This
> allows me or anyone else to apply the patch like this:
>
>   $ patch -p0 --dry-run < my-changes.diff
>
> If the --dry-run doesn't spew a bunch of errors, I'll apply it:
>
>   $ patch -p0 < my-changes.diff
>
> Hope that helps.
>
> ---
> Ted Roth
> PGP Key ID: 0x18F846E9
> Jabber ID: address@hidden






reply via email to

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