Re: [avr-gcc-list] How to handle interrupt vectors ?

[Charalampos Alexopoulos]

dlc wrote:
>
>
> Pink Boy wrote:
>> Charalampos Alexopoulos sez,
>>
>>> Thank you for your answer, but i am not looking for the
>>> easiest way. I want to have some solution similar to previus
>>> example. I can use ISR's even with c++ with no problem, what i need,
>>> as i said before, is  to assign a  vector as  a static class member
>>> in a way similar to other types like :
>>>
>>> class foo
>>> {
>>>     public:
>>>           static constant uint8_t data = 0x0a;
>>>           ...
>>> }
>>>
>>> then you can use it from some other class like:
>>>
>>> uint8_t local_data = foo::data;
>>
>> You scare me.  Run away.
>>
>> I always worry with C++ that I really don't understand what the
>> compiler is doing when it calls functions.  I guess my thought is
>> that if you can't define the function as an isr inside the class
>> then what you are trying to do isn't supported.
>>
>> If I were you and I'm not, I would have an ISR call your static
>> function, then exit.  That will most likely work.  In general
>> though I like to keep what I'm do in an ISR very simple (buffer
>> data, generate events, time critical stuff) and let the main loop or
>> a task handle the complex stuff.
>
>
>   I totally agree.  An ISR is NOT the place to put "pointer chasing"
> C++ dribbles.  I don't even like to call a function there!  There is
> no rule that says that every construct in a C++ program has to use the
> C++ object paradigms.  Define your ISR's using the smallest possible
> code. You will NEVER be dealing with an ISR as part of another object,
> nor will you ever likely inherit from an ISR.  Realistically ISR's are
> a thing apart from the rest of the program (usually) so this is rarely
> an issue.
>
> IMO, IME,
> DLC
>
Thank you all for you suggestions, but let me clarify something. An ISR
is used with a vector as a parameter, what i want to do is instead of
writing immediately the vector name, i will get it from a class. Note
that i want to have it as a constant so it can't change during runtime.
There is nothing uncertain in this approach and nothing to scare about.
I am not dealing with ISR as part of another object and of course
inheritance has nothing to do with this. The ISR call is part of the
main file and only the name of the vector is given in a static way from
another class which for the compiler point of view is the same like i
was put it directly.