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

[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


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


reply via email to

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