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

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

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


From: Jörg Diederich
Subject: RE: [avr-libc-dev] vector section disable, vector redirection
Date: Wed, 15 Aug 2007 20:46:01 +0100

hello,

> ----- Original Message -----
> From: "Eric Weddington" <address@hidden>
> To: "'Jörg Diederich'" <address@hidden>, address@hidden
> Subject: RE: [avr-libc-dev] vector section disable, vector redirection
> Date: Wed, 15 Aug 2007 11:55:24 -0600
> 
> > > 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.
> >
> > yes, that's correct. as there were all vectors defined by
> > default, overhead is introduced for unused vectors.
> 
> Code size is usually the primary criteria. I would not recommend using a new
> interrupt system at the cost of adding more code size. Though your methods
> might be useful for some users who might need such a system.

well, maybe the whole redirection-talk misleads my intention. i do not want to 
discuss a new interrupt system. 
as code size is often the main criteria, a simple jump is of course the best 
solution. apart from diabling all vectors, the way the avr-libc performs that 
works very fine for me. my reason to describe the environment was to explain 
the reason to change another way and to present a solution. or, in short words: 
the "why" and a thinkable "how".

ok, i will give it another try: at least in my opinion, a library should offer 
as many support and possibilities as possible. and the way the vector names are 
processed at the moment prohibits a free use by any user.
currently, vector names are processed by the preprocessor in the following way 
(taken INT0 again as a representative):

in (most) io.h files
#define INT0_vect                       _VECTOR(1)
->
an ISR(INT0_vect) will be processed in interrupt.h to
void _VECTOR(1) (void)
->
further processed with the help of sfr_defs.h to __vector_1 to 
void __vector_1 (void)
->
symbol used in gcrt

for some unknown reasons, the effort is made to include the _VECTOR(x) macro in 
all relevant io-header-files. quite a lot. ok, library source size is assumed 
to be negligible :). 
future changes in the interrupt system could therefore require to re-process 
each io.h. additionally, and more important to me, it prohibits to use the 
vector name in a free (numeric) way. 
there are no disadvantages in moving the _VECTOR(x) to a central place:

#define INT0_vect                       1
-> interrupt.h
void _VECTOR(1) (void)

and the same procedure as now goes it's way. it's just a simple and in my 
opinion advantageous other sequence of the already in-use preprocessor 
procedure. 

and yes, of course, i might be wrong :)

bye jörg

=


-- 
Powered By Outblaze




reply via email to

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