AVR-Chat

On Fri, 2005-08-05 at 09:55 -0500, Zack Widup wrote:
> You can do it that way, but I assume if I am not planning on using a
> given interrupt, it doesn't matter what is in that vector location.
> It hasn't gotten me into troble yet (fingers crossed!).  What I
> usually do is:
> .ORG 0000
>    RJMP Reset
> .ORG 0003  
>    RJMP Timer
> .ORG 0009
>    RJMP ADCSVC

[extraneous text deleted for brevity]

Zack:

   While this will work, and deos save a small amount of typing, it
would not fall into the categpry of "recommended coding practices," at
least., not in MY book.  *grin*

   The reason being that while you may not EXPECT certain interrupts to
occur, they can, and sometimes will occur.  By having an explicity RETI
for each possible interrupt vector, you avoid the complications of
unpredictable execution of interrupt handling routines.

  As for the typing, there is a very simple solution:   create a
"skeleton" interrupt vector table in a text file, name it something like
"i_vectors.inc" and simply use your text editor to read it into the
appropriate location in your program source file (or even use
the .include directive).   I personally prefer to explicitly read the
skeleton routeins into my source file, so that the code they contain
appears in my source listings, but that is a matter of personal
preference, and there is little to argue that either approach is
functionally superior.

   If you work with multiple different AVR chips, with differing
interrupt tables, you can just create such a file for each chip, and add
the chip name to the file name (e.g., 8515_i_vectors.inc).

   Another approach is to have an include file for each chip type with
which you workm that includes not only the interrupt tabl;e skeleton,
bnut the register name definitions, and any other "standard" equates and
defeins, macros, etc., that you tend to use in all  programs.  (As most
of the AVR C compilers offer for each chip type).

  FInally, not to put too fine a point on it, but I HIGHLY recommend
massive, verbose commentary in source code.  Indeed, my source code
files are often 60% or more comments, as opposed tothe code content.
There are several reasons for this.  For one thing, you cannot expect to
remmeber what it was you were thinking when you wrote a specific piece
of code, when reviewing it years (or evenm months) later.  Also, if you
are planning to share your code, the more complete and detailed the
commentary, the easier it wil be for others to understand what you ahve
written.  This issue of commentary applies espeically to header/include
files such as I discuss above.  Do not assume that becase a line reads:

.EQU	PWM_CONTROL	0x36

  That everyone will understand that hex 0x36 is the address of the PWM
control register.  Include a comment to that effect:

.EQU	PWM_CONTRAL	0x36		; PWM Control register I/O addy

  Itis more typing, yes, but it makes it absolutely clear what the line
means.  No room for misinterpretation.

  OK...lecture mode off  (sorry, I am a frustrated teahcer/wannabe)

Tom Keller
aka avrFreak