forums.ps2dev.org

[jean]

I'm trying to figure out the usage of some PSP interrupts. I searched and found only examples on the SIO port. To be clearer, I do know how to set up an handler , but i don't know how to manage the rest - i'm referring to the part

[TyRaNiD]

That code is specific to the UART used for SIO, it reads the interrupt state and then clears it, if you didn't do that it would keep repeating the interrupt indefinitely, no idea what the equivalent is for audio but I question your need for using one :)

[J.F.]

Besides, if you used the search, you'd find a big thread that covered how the PSP handles ints as well as what all the various int register bits are for. Me and hilde and a few others posted quite a bit on that.

[Yury]

[hlide]

[J.F.]

[jean]

[TyRaNiD]

I don't see how using an interrupt is going to save you much in the way of time, the audio code should already be in effect interrupt driven just you don't see it. And the overhead for a thread is not massive really, compared to the fact that the interrupt is context switching anyway and the kernel does the odd switch. I would like proof that something which perhaps gets called only a small number of times per second (what 60 or so?) can make any real difference :)

[J.F.]

[hlide]

at this point, i have a question.

I heard threading model is based on a cooperative thread scheduler. Does it mean if an interrupt occurs, you need to wait for the current thread to block so the thread owning the callback to execute may run ? or does it mean there is a special thread or a safe context which allows an interrupt for a callback to run it kind of preemptively ?

I must admit having several threads in a cooperative way to output a sound makes me wonder how the sound may be accurate depending on the programming quality of the code and the priorities of threads.

[TyRaNiD]

The interrupt handler is always called as it is not part of a thread, however all the interrupt handler can normally do is set some sort of thread primitive (say an event flag or semaphore) to "unlock" a waiting thread. At this point if the priority of the waiting thread is high enough it will preempt anything else.

In the end it is a case of ensuring thread priorities are based on how interrupt driven a thread is likely to act, so some thread which just does endless calculation and never waits should at a low priority while something like the audio thread should be high as it will sit in a wait state 90% of the time.

[hlide]

[jean]

@tyranid

[hlide]

@jean

The facts are : most audio functions are not callable from an interrupt, so you would need to take in charge all the audio stuff, which also means you need to take in charge the DMA part of audio as to be sure not to mess with those of PSP firmware. I just can tell you that redirecting an interrupt is not enough to make your idea to work but you will need all the hardware registers details about audio and DMA to code your own audio manager - which i doubt a lot of us have this knowledge here.

By the way, how do you redirect an interrupt ? through a kernel function like sceKernelRegisterIntr/sceKernelRegisterSubIntr ?

[TyRaNiD]

It does no polling what so ever, the thread primitives handle the wait state and some code inside the exception handler is responsible for thread dispatch so when you ask for a thread to be resumed inside an interrupt handler it will switch to the thread to handle it.

Yes this is going to waste cpu cycles but it is questionable whether it makes a significant difference. Certainly reimplementing the entire audio library just to remove abit of cpu usage seems awfully wasteful, now of course if you have an example of non-trivial code where the thread switch is the main performance issue then I might start caring :P

[jean]