[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] Interrupt vector redirection scheme
From: |
Michael Schulze |
Subject: |
Re: [avr-libc-dev] Interrupt vector redirection scheme |
Date: |
Mon, 03 Sep 2007 10:59:09 +0200 |
User-agent: |
Thunderbird 1.5.0.12 (X11/20070719) |
Hi,
Very interesting idea. Though there is a discrepancy: function
redir_func() keeps the SREG already after it is scratched (sbiw,
eor).
I can't find the definition of that function. Where is it defined?
Ok. Let me explain my intention shortly. I wanted to write a flexible
possibility for changing the interrupt code at runtime. Try to imagine
the following scenario:You have a very thin HAL or small operating
system which offers the possibility of loading and executing of
different applications (one at a time) depending on the actual state or
environment. The applications use different interrupt service routines
for the same interrupt source. If you want changing the ISR at runtime,
your solution will work for a previously known configuration. However,
it will fail if you don't know the kind and second the number of
applications are installed on the device. My imagination was to allow
that and also in case of installation of application at a later time
without changing other parts of the flash (sure, the application have to
be build against specific flash addresses)
If you want to allow that behavior in C, it looks like that:
typedef void (*funcpointer)(void);
funcpointer fp;
ISR(TIMER1_OVF_vect)
{
if (fp)
(*fp)();
}
Attention: The function pointer has to be set with interrupts disabled,
because of changing a word and on the AVR isn't atomically.
The solution in C works perfectly but in case of more than two
redirections it is very expensive. What are the possibilities to allow
it cheaper?
1. a redirection table for all interrupts, like Jörg Diederich
presented a couple of days before
2. my solution which allows a more fine granular configuration
Why I posted my solution on the list, was the intention to present a way
for dynamic binding of ISR's and I want give something back to the
community. In my opinion, the solution can be integrated without side
effects. If you don't want to used it, you don't have to pay for it. If
you need or want this functionality, you have to pay for it. Dynamicity
isn't for free. I think, there it should be.
Regards,
Michael
smime.p7s
Description: S/MIME Cryptographic Signature