forums.ps2dev.org

[M.Jackson]

I am working on a small project where i try to utilize Booster's mighty IPL sdk to read input from the PSP buttons. At first it worked fine, until tens of seconds later the status reading routine - _pspSysconGetCtrl1 that the sdk provides - appeared malfunctioning. it either constantly returned all-zero status despite i kept pressing those buttons, or got stuck at somewhere inside (it just never returns again, probably the while loop in syscon_cmd). And the time it takes from working to became malfunctioning varies from time to time (seems random to me). I have done almost everything that the example code in iplboot does for initialization before invoking _pspSysconGetCtrl1/2, but it still does not work as i expected.

Has anyone experienced similar problem when using the ipl package? is there any idea how to get over this?

Thanks!

[J.F.]

The solution is easy - fix the bugs in your code. See? Wasn't hard at all.

[saulotmalo2]

[M.Jackson]

fixing the bug in my code. is it that obvious? what kind of bug are you suggesting? when i said the reading routine was malfunctioning, i was not talking about the code i wrote. i was talking about the _pspSysconGetCtrl1 routine that the sdk provides. since there is a lack of specifying documents for the sdk (which is understandable), i was thinking if i did all the things that the example code does beforehand, i should be able to get the button status at any time when i call that function (no matter how many times or how frequently i call it), unless there is some other restrictions of using this routine that we don't know yet. i was hoping there might be someone out there who is experienced and wise enough to know what might lead to this.

thanks for your reply, though your answer is not exactly the one i was looking for.

[adrahil]

How about showing the code where it goes wrong and telling about the context of its execution? ;)

[J.F.]

You stated your problem, then blatantly blamed a bug in the OS. Not much we can do to help with that. If you wish for us to verify the bug is NOT in your code, you'd have to post said code first. While it IS possibly a bug in Sony's kernel (they've had a number of them), it's far more likely a bug in your code. You can either try to locate it yourself, or post code if you really wish for help.

My comment was not strictly aimed at you, but at every newcomer whose first post is nothing more than "I've got some kind of problem. What is the solution?" :)

[M.Jackson]

Haha, problem solved! It turns out that function can not be called as frequently as i wanted, as i reduced the invocation rate from like extreme high to just about 10 times per second, it work! A good night of sleep to clear my mind really helps.

Btw, starting up with the ipl package means the sony kernel/firmware is no longer there for use, hence the bug is either in my code or the ipl package (or the hardware, though it is almost impossible). but you are right, it is more possible to locate the bug in my code than somewhere else. So if i were in your shoes, i would have had the same comment in mind. But i would never post the words you said there, as they are no more helpful than "could it just be a bug in your code?" or "just post your code so that everyone can help".

[J.F.]

[adrahil]

Good job :)

And when people ask you to post the code, it is not because they doubt your C capacities, but it happens quite often that some hardware subtility will cause problems if you do things your way. And there are loads of people - who DO know the hardware better than you - around who can help - if the problem statement includes the usage case. (This kind of stuff happens a lot with Gu/Gum for instance)