| genius needed [message #99711] |
Mon, 28 July 2008 09:07  |
![jeremy luzier[1] is currently offline](/theme/PARIS_Forum_Template/images/offline.png "jeremy luzier[1] is currently offline")
jeremy luzier[1]
Messages: 18
Registered: March 2008
|
Junior Member |
|
|
"Save Attachments"
>> from the File menu to save.
>
>Well, an hour of testing and it seems solid here, both with PARIS and
through ASIO. I can't tell the difference from the last build, but I
guess that's the point.
If you're tackling the IRQ assignment glitches in the PSCL, and
everything depends upon the PSCL - do you think this could also have a
global positive effect on PARIS' IRQ twitchiness overall?
- K
On 2008-09-21 10:03:35 -0700, "Mike Audet" <mike@...> said:
>
> Thanks, Kerry!
>
> In the latest build, I reset the delays to zero. So, it should be faster.
>
> Cheers!
>
> MikeHi Kerry,
I've just been looking at the Scherzo and I'm certain I know what has been
happening. There is function that is called when the hardware interrupts
called an ISR. It does the following:
1) read what the interupt state is.
2) set the interupt state to mas
|
|
|
|
| Re: genius needed [message #99714 is a reply to message #99711] |
Mon, 28 July 2008 09:26  |
Tom Bruhl
Messages: 1368
Registered: June 2007
|
Senior Member |
|
|
ked (ignore).
3) Calls a delayer procedure call that runs later and actually does the work
and resets the mask to how the ISR found it.
4) returns
This is a really clean, quick, efficient ISR. I don't think there is anything
wrong with it. I suspect that PARIS is just sensitive to other badly written
ISRs because it needs to work in real time.
The problem on a Multi-processor machine is that two interrupts can be called
on two CPUs at the same time, or slightly different times.
A second call can come in a little after a first call and, to make a long
story short, when it checks to see what the IRQ state is, it records that
it is masked (off) because the other ISR just masked it. The 1st one finishes
and restores the IRQs to unmasked (good). When the second one finishes,
it restores the IRQ mask to how it found it, which is masked. From then
on, there are no more samples requested by the card.
The version of the PSCL I just posted works around this because when this
happens (which is rare), it just unmasks the Interrupt.
It should work fine until I can fix the Scherzo.
So cool!
:)
KerryGalloway <kg@kerrygalloway.com> wrote:
>Well, an hour of testing and it seems solid here, both with PARIS and
>through ASIO. I can't tell the difference from the last build, but I
>guess that's the point.
>
>If you're tackling the IRQ assignment glitches in the PSCL, and
>everything depends upon the PSCL - do you think this could also have a
>global positive effect on PARIS' IRQ twitchiness overall?
>
>- K
>
>On 2008-09-21 10:03:35 -0700, "Mike Audet&quo
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The PARIS Forums
Search
Help
Members
Register
Login
Home
