Code: Select all
/* Read out the interrupt state and clear it */
u32 stat = _lw(0xBE500040); // these codes are valid for SIO intr only??
_sw(stat, 0xBE500044);
(Audio?) Interrupt handler
(Audio?) Interrupt handler
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
If i try to set up an audio intr handler, for instance, leaving the handler empty causes -quite obviously- the PSP to hang or shut down. Can anyone point me to a list of intr flags or someting like it??
J.F.,J.F. wrote: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.
I did the search on 'interrupt handing' in the PSP forum and the results are 140 messages in 71 threads
Did you mean this thread ?
Could you please provide us with a bit more specific reference to the thread you have mentioned ?
PS
Reading the forum it is a pity sometimes to find quite an interesting question being answered "use search, this subject has been discussed a lot ...."
Maybe simple link to the faq (or any other "smart index") might be much more helpful .....
Oops! Sorry about that. It's.... the KEYBOARD! The keys are messed up! Yeah! That's the ticket!hlide wrote:hLIde like in kLYde :)J.F. wrote: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 - you'll find the big thread in a link in that thread you mention. Said link being:
http://forums.ps2dev.org/viewtopic.php? ... c&start=30
well, there are TONS of motivations to drill down on interrupt usage...to be coherent with my initial post, i could mention a faster audio manager. Speaking on the base of my pc programming experience, i think PSP_AUDIO_INT and PSP_DMA0_INT or PSP_DMA1_INT could be used to summon a procedure every time an audio buffer needs to be filled, instead of wasting CPU cycles handling multiple threads. In this pspsdk's source for "pspAudioLib" we find:no idea what the equivalent is for audio but I question your need for using one :)
Code: Select all
static int AudioChannelThread(int args, void *argp){
// ...
callback(bufptr, PSP_NUM_AUDIO_SAMPLES, AudioStatus[channel].pdata);
// ...
pspAudioOutBlocking(channel,AudioStatus[channel].volumeleft,AudioStatus[channel].volumeright,bufptr);
bufidx=(bufidx?0:1);
// ...
}
Code: Select all
int thread1 (SceSize args ,void * argp){ // producer
while(1){
callback(bufferA);
waitFlagB();
callback(bufferB);
waitFlagA();
}
}
int thread2 (SceSize args ,void * argp){ // consumer
while(1){
outputBlocking(bufferA);
setFlagA();
outputBlocking(bufferB);
setFlagB();
}
}
Oh, my... same old story "you could have used "search" instead of p*****g us off" ...Well, i DID search for "audio interrupt" and so on... results?? none. At least none of interest in the first 50... (in fact, even his majesty tyranid doesn't know how to manage it :) )Besides, if you used the search, you'd find...
Anyway, thanks J.F. i will read that huge thread on ucLinux...
jean
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 :)
You don't have to read the whole thing - the link goes to the start of the section of interest and continues for only a few pages.jean wrote: Anyway, thanks J.F. i will read that huge thread on ucLinux...
jean
If you plan to develop anything of significance, you need to be prepared to do in-depth research. Idly searching a term and glancing over thread titles won't hack it. You need to be prepared to go through DOZENS of long threads, use google, hunt down PDFs, look over examples found elsewhere, etc, etc. When your boss tells you to get the project done, he isn't going to accept "I started a thread, but no one will give me step by step instructions how" as an answer. We're not here to make your task easier, just possible.
Look at it this way - we'll put almost as much effort into answering someone's questions as they did looking for the answers themselves. Make a half-assed search, you'll get a half-assed response. Make no effort, and we'll make no response.
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.
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.
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.
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.
to be sure to understand, we can sum up this way :TyRaNiD wrote: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.
if a thread never blocks (waiting for an event, sleeping, etc.), the only chance for other threads to run is that an interrupt raises one of the other threads when priority is higher, whence your advise about how to choose a priority of a thread.
Long ago I noticed when you set a callback for GU, and you wanted to use VFPU in it, PSP crashed. I was wondering if this callback was executed in the running thread which may not VFPU-aware or it is because it runs in a special thread or context which is not VFPU-aware. I guess the only option is to send an event to another more prioritized VFPU-aware thread.
In case you may ask why we (Mr[iCE] and I) wanted to do so, it was for experimental needs.
@tyranid
while interrupt handlers are called "directly by hardware" and do not need to wait anything.
@J.F.
I rely on the fact that a wait-for-flag function is always more or less a poll-and-wait, something likeI don't see how using an interrupt is going to save you much in the way of time
Code: Select all
while(!isFlagSet(flag)) sleep();
Yes, "a small number of times per second" if you have a big buffer. If for some reasons you need to reduce latency (let's say realtime audio synthesis), you need to reduce buffer size and therefore to increase the frequency of calls to your handler.perhaps gets called only a small number of times per second
@J.F.
Please, don't try to teach me "from the great height". Maybe I'm not a psp dev guru, but I bet I can be of help, and sure I spend 4/5 of my life researching and studying; i'm not here to exploit anyone, and if searching a term on a forum requires more than a degree, then I will give up shortly. I'm not an idiot, please don't treat me as if i was. The point is that i'm not having my questions answered even after the read of the thread you suggested. I'm beginning to think you've not understood the question. So let me tell you how I'm gonne behave: i will post reasonable questions (that i will answer alone sometimes if i find the solution myself) and reasonable answers to reasonable questions. Stop. I will never act the million-dollar-man part if i have nothing interesting to say. Now, let the discussion return to interrupts, pedagogy is definitely O.T.If you plan to develop anything of significance, you need to be prepared to do in-depth research. Idly searching a term and glancing over thread titles won't hack it...etc...
@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 ?
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 ?
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
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
Yep, this is what i'm doing while experimenting by now...is it wrong?By the way, how do you redirect an interrupt ? through a kernel function like sceKernelRegisterIntr/sceKernelRegisterSubIntr ?
Ok, tyranid...you catched me :) I'm working on something, and I'll surely let you know when I'll have nice code to show, even if I cannot give guarantees on the time it will take (i have a full life in this moment...)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
If you tell me it's so hard, given the reasonable motivation you mention, then i thrust you. This means that for now i will continue developing without the entire interrupt replacement stuff, on wich i can work in another moment....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...
In the meanwhile, thank you all guys...your help is priceless.
j