Hi Jon,
> I am writing code for audio I/O that uses the
standard Codec ISR. But I need
> to do some of my own processing in the ISR as well--basically continuing
to
> perform the functions of the kernel's Codec ISR, but adding my own
code after
> it. The stock ISR does an RTI when finished, and I was hoping to instead
> jump
> to or call my code before the RTI. Any ideas on that?
How I would try...
Look into the interrupt table.
Store the jump target for the ISR.
Replace it by the address of an own function,
which sets a bit which triggers the main loop or raises a software ISR with
lower priority.
Then jump to the original ISR routine which afterwards cleans up with its
RTI.
After that you'll get your own routine called by either reacting to the set
bit
within the
main loop or because a software ISR which holds your routine is launched as
soon as
the Codec ISR returns.
Just my 2 cts...
Bernhard
AW: 21065L Ez-kit kernel source?
Started by ●July 7, 2005
Reply by ●July 7, 20052005-07-07
Good suggestions! I think the software interrupt method is the way to go.
My
main loop is busy processing a block of data, which is why I need to add code
to the codec ISR in the first place, so setting a flag to be polled in the main
loop will not work for me.
It surprised me that there was no similar example in the supplied code from
ADI. I was looking for something that implemented block-based audio
processing--while processing one block, the next block is buffered for later
processing. The closest thing I found was the FFT example, but while it is
computing the FFT, it ignores new incoming data until it finishes!
--- Bernhard Holzmayer <Holzmayer.Bernhard@Holz...> wrote:
> Hi Jon,
>
> > I am writing code for audio I/O that uses the standard Codec ISR. But I
need
> > to do some of my own processing in the ISR as well--basically continuing to
> > perform the functions of the kernel's Codec ISR, but adding my own code
> after
> > it. The stock ISR does an RTI when finished, and I was hoping to instead
> > jump
> > to or call my code before the RTI. Any ideas on that?
>
> How I would try...
>
> Look into the interrupt table.
> Store the jump target for the ISR.
> Replace it by the address of an own function,
> which sets a bit which triggers the main loop or raises a software ISR with
> lower priority.
> Then jump to the original ISR routine which afterwards cleans up with its
> RTI.
>
> After that you'll get your own routine called by either reacting to the set
> bit within the
> main loop or because a software ISR which holds your routine is launched as
> soon as the Codec ISR returns.
__________________________________________________
main loop is busy processing a block of data, which is why I need to add code
to the codec ISR in the first place, so setting a flag to be polled in the main
loop will not work for me.
It surprised me that there was no similar example in the supplied code from
ADI. I was looking for something that implemented block-based audio
processing--while processing one block, the next block is buffered for later
processing. The closest thing I found was the FFT example, but while it is
computing the FFT, it ignores new incoming data until it finishes!
--- Bernhard Holzmayer <Holzmayer.Bernhard@Holz...> wrote:
> Hi Jon,
>
> > I am writing code for audio I/O that uses the standard Codec ISR. But I
need
> > to do some of my own processing in the ISR as well--basically continuing to
> > perform the functions of the kernel's Codec ISR, but adding my own code
> after
> > it. The stock ISR does an RTI when finished, and I was hoping to instead
> > jump
> > to or call my code before the RTI. Any ideas on that?
>
> How I would try...
>
> Look into the interrupt table.
> Store the jump target for the ISR.
> Replace it by the address of an own function,
> which sets a bit which triggers the main loop or raises a software ISR with
> lower priority.
> Then jump to the original ISR routine which afterwards cleans up with its
> RTI.
>
> After that you'll get your own routine called by either reacting to the set
> bit within the
> main loop or because a software ISR which holds your routine is launched as
> soon as the Codec ISR returns.
__________________________________________________
Reply by ●July 8, 20052005-07-08
...
> It surprised me that there was no similar example in the supplied code from
> ADI. I was looking for something that implemented block-based audio
> processing--while processing one block, the next block is buffered for later
> processing. The closest thing I found was the FFT example, but while it is
> computing the FFT, it ignores new incoming data until it finishes!
> ...
Oh, there is, indeed, not only an example, but this is the concept of VDK
device drivers:
the ISR does only the very basic and absolutely necessary minimum.
Keeping ISRs small/short results in high responsability of the system.
Then, the ISR triggers the activatate method of the device driver component.
Which, in fact, is a sort of software interrupt,
(managed in a sort similar to how Linux handles its "bottom half" stuff).
This activation method is the place where you usually do most of the ISR work.
These methods are arranged between the ISR and the thread level, thus being
prioritized and,
as long as timing constraints are not broken, guaranteed to run after every ISR
call
which flags them.
Bernhard
