RE: [avr-libc-dev] vector section disable, vector redirection

[Eric Weddington]

> -----Original Message-----
> From:
> address@hidden
> [mailto:address@hidden
> org] On Behalf Of Jörg Diederich
> Sent: Tuesday, August 14, 2007 4:16 PM
> To: address@hidden
> Cc: address@hidden
> Subject: [avr-libc-dev] vector section disable, vector redirection
>
> hello,
> i've been working on a part of software which bases on
> another, already installed part of software at the avr. in
> order to use interrupt vectors in the part mentioned first,
> two steps were necessary. for both i'd like to discuss an
> improvement in the current avr-libc.
>
> first, it was necessary to prevent any vectors are included.
> this could easily done by including '*(.vectors)' in the
> DISCARD-section in the linker script. Unfortunatly, the
> '__bad_interrupt' func of the gcrt references section
> .vectors. it can't easily discarded too because it is placed
> in the .text-section.
> as an easy workaround i would suggest to use another, special
> named section for this. one simple name would be
> .bad_vectors. this would enable to discard this in a simple
> way. the only neccessary changes in avr-libc would be to
> include .bad_vectors right after .vectors in any linker
> script. the advantage would be in a simple way to remove any
> vectors from a linked applicaton. if i remember correctly, it
> is possible to use vector space as normal program space, btw.

I like the idea of being able to optionally remove the vector section. I
have had a customer ask about if such a thing could be done. Would you be
willing to work up patches that implements such an idea? I know that you
will also have to patch GNU Binutils to change the linker script.


> second, a redirection of all interrupts is performed. on
> every interrupt a table in SRAM is asked for the function
> pointer to jump to. a naive approach results in very much
> program space, as the avr-gcc pushed and pops all registers
> in an ISR with an call inside (3,2kB on the at90can128).
> using naked ISR's is not the smallest thinkable way, as in
> every ISR the same instructions are included. that's why my
> supervisor and me developed the redirection scheme attached
> below (ca. 500byte). for me it's unknown if there is any
> place in the avr-libc for vector redirections, but any hints
> are very welcome *g*. (i'm sorry for long posting, but
> attachment are often ignored, 'cause of more effort)
> the weakness of the redirection table is the set of a vector
> name in the following procedure:
>
<snip>

I'm not so sure about this one. If I understand your example code, this
would be permanently changing the way that interrupts are handled now to do
this redirection, but at a cost of adding this extra code. If an ISR calls a
function then this vector redirection would produce smaller code than the
current implementation, correct? But if the ISR does not call a function,
then it looks like this vector redirection system would still introduce a
code overhead, correct? If so, then doing this would be unacceptable for
smaller devices with minimal code space.

Plus, you're proposing to make these changes:

#define ISR(vector)                                     \
  void vector (void) __attribute__ ((signal)); \
  void vector (void)
#endif

...

/* External Interrupt Request 0 */
#define INT0_vect                       1
#define SIG_INTERRUPT0                  1

Which means that when I write:

ISR(INT0_vect)
{
....
}

Then it will be preprocessed into:

void 1 (void) attribute__ ((signal));
void 1 (void)
{
...
}

I thought that symbols had to start with a letter, not a number...

Somebody please correct me if I'm wrong.

Have you (and/or your supervisor) actually implemented and tried this
scheme?

Eric Weddington