PSP remote control pinout?
Hm, another interpretation of the MSB in the command byte could be that MSB=1 means command, and MSB=0 means response, ie the periodic 0x02 messages from the PSP might be in response to the 0x82 command issued by the remote at connection time.
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people
Having the courage
Getting over crisis
I rescue the people
-
Guest
The first log was from sysem powerup (the PSP was off, not sleeping).
As you can see, it's the remote which initiates the negotation. Which kind of makes sense, since the remote knows there is a PSP to talk to (since it has power), but the PSP might not know that there is a remote attached.
Of course, had the remote _not_ initiated the negotiation, maybe the PSP would have said something. My current snooping device is just piggy-backed on the remote, so it can't prevent the remote from speaking up.
Either way, a terminal device could of course initiate a negotiation as well. The 0x80 command has some parameter bytes, and I'm guessing these are used to identify the type of device connected. There could also be any number (well, a bit over 100 at least) of commands to request specific kinds of services from the PSP.
As you can see, it's the remote which initiates the negotation. Which kind of makes sense, since the remote knows there is a PSP to talk to (since it has power), but the PSP might not know that there is a remote attached.
Of course, had the remote _not_ initiated the negotiation, maybe the PSP would have said something. My current snooping device is just piggy-backed on the remote, so it can't prevent the remote from speaking up.
Either way, a terminal device could of course initiate a negotiation as well. The 0x80 command has some parameter bytes, and I'm guessing these are used to identify the type of device connected. There could also be any number (well, a bit over 100 at least) of commands to request specific kinds of services from the PSP.
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people
Having the courage
Getting over crisis
I rescue the people
Yes, it seems that way. For a while I though we had written off that pin as not being able to give power, but when reviewing the thread I see that that was just pin 4 (green). Also checking your oscilloscope grabs, I notice that pin 5 is the only one which makes a clear transition at powerup without any transients.
In view of the insight in the protocol we now have, I'd also like to withdraw the RTS/CTS hypothesis. Since flow control is handled through the 0xF0/0xF8 handshaking, there is no need for such signals.
In view of the insight in the protocol we now have, I'd also like to withdraw the RTS/CTS hypothesis. Since flow control is handled through the 0xF0/0xF8 handshaking, there is no need for such signals.
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people
Having the courage
Getting over crisis
I rescue the people
Here's one for digging up dead threads...
I've recently come across some interesting information about the PSP's Remote Control port that, while it might be hearsay or not, deserves to be mentioned. The source is a confirmed Sony employee, but I can't guarantee where he got his info from.
Obviously the remote control port is used to control Audio playback. What has not been fully explored (to my knowledge) is if it might be a vessel for other types of data communication other than the simple "Play/Stop/Next" commands sent from the remote control.
My source (whom I trust to be forthright and honest) has mentioned a couple of interesting ideas that I do not take any responsibility for if they are totally false or totally whack:
1) When a defective PSP unit is returned to Sony (one with damaged firmware). A special dongle is attached to the remote control port to reflash the firmware with a proper working image. If we can only find the command sequence that the little dongle sends....Marcus has already been pretty successfull in sniffing the commands sent by the remote itself.
2) The port is purported to contain a "debugging" function. I don't have any more info on that and no way of finding out if the debugging goes on through a PS2Tool or whatnot.
3) A cable connects from the PSP's Remote Control port to a development unit for UMD emulation, power, and again debugging. Is this really plausible? I don't know. Full UMD emulation through that little port? Seems fishy. Wouldn't the USB port be a little bit more suited for this kind of work? But then again this might be a slight-of-hand trick meant to keep prying minds away from Sony's little secret...
I know there's not much to look at unless we can get access to say the "firmware reflashing dongle" (if it even exists!), but I just wanted to raise this topic up from the dead.
Call me skeptic on all of this but I just wanted to get some feedback on this little bit of info that I received. I hate being that person that just throws out "ideas" and never does anything...so while I "throw" this idea out I'm going to go see what I can start digging up (if anything).
I would appreciate any ideas/thoughts.
I've recently come across some interesting information about the PSP's Remote Control port that, while it might be hearsay or not, deserves to be mentioned. The source is a confirmed Sony employee, but I can't guarantee where he got his info from.
Obviously the remote control port is used to control Audio playback. What has not been fully explored (to my knowledge) is if it might be a vessel for other types of data communication other than the simple "Play/Stop/Next" commands sent from the remote control.
My source (whom I trust to be forthright and honest) has mentioned a couple of interesting ideas that I do not take any responsibility for if they are totally false or totally whack:
1) When a defective PSP unit is returned to Sony (one with damaged firmware). A special dongle is attached to the remote control port to reflash the firmware with a proper working image. If we can only find the command sequence that the little dongle sends....Marcus has already been pretty successfull in sniffing the commands sent by the remote itself.
2) The port is purported to contain a "debugging" function. I don't have any more info on that and no way of finding out if the debugging goes on through a PS2Tool or whatnot.
3) A cable connects from the PSP's Remote Control port to a development unit for UMD emulation, power, and again debugging. Is this really plausible? I don't know. Full UMD emulation through that little port? Seems fishy. Wouldn't the USB port be a little bit more suited for this kind of work? But then again this might be a slight-of-hand trick meant to keep prying minds away from Sony's little secret...
I know there's not much to look at unless we can get access to say the "firmware reflashing dongle" (if it even exists!), but I just wanted to raise this topic up from the dead.
Call me skeptic on all of this but I just wanted to get some feedback on this little bit of info that I received. I hate being that person that just throws out "ideas" and never does anything...so while I "throw" this idea out I'm going to go see what I can start digging up (if anything).
I would appreciate any ideas/thoughts.
-
Guest
Amazing how people think along similar lines :)
I was wondering about this myself, since the remote port is merely a serial port. The PSP could make any protocol it wants on that line depending on what it wants to do with it. It may even be able to make it into a memory-stick port, so say... flashing ?
But that is all speculation, but the information you came across provides some hope.
FYI, I ran across this web site the other day:
"Sony 9-pin Remote Protocol" http://www.rmbwoc.com/vidpage/s9pin.html
It may not reflect the precise protocol used in the PSP, it may reflect something similar and its capabilities.
I was wondering about this myself, since the remote port is merely a serial port. The PSP could make any protocol it wants on that line depending on what it wants to do with it. It may even be able to make it into a memory-stick port, so say... flashing ?
But that is all speculation, but the information you came across provides some hope.
FYI, I ran across this web site the other day:
"Sony 9-pin Remote Protocol" http://www.rmbwoc.com/vidpage/s9pin.html
It may not reflect the precise protocol used in the PSP, it may reflect something similar and its capabilities.
Holy cow, that document dates back to 1996!?! Heh...gorim wrote:Amazing how people think along similar lines :)
I was wondering about this myself, since the remote port is merely a serial port. The PSP could make any protocol it wants on that line depending on what it wants to do with it. It may even be able to make it into a memory-stick port, so say... flashing ?
But that is all speculation, but the information you came across provides some hope.
FYI, I ran across this web site the other day:
"Sony 9-pin Remote Protocol" http://www.rmbwoc.com/vidpage/s9pin.html
It may not reflect the precise protocol used in the PSP, it may reflect something similar and its capabilities.
I was thinking that since Marcus was able to sniff the remote's data he could use his USB sniffer to retransmit data to the port ( I can't remember if he was able to transmit his own commands or not and I'm too lazy to read right now)...transmit lots of random data to see what pops up, maybe?
See Feb 06, 2005 post: http://forums.ps2dev.org/viewtopic.php?p=6238#6238roto wrote: ...
I've recently come across some interesting information about the PSP's Remote Control port that, while it might be hearsay or not, deserves to be mentioned. The source is a confirmed Sony employee, but I can't guarantee where he got his info from.
Obviously the remote control port is used to control Audio playback. What has not been fully explored (to my knowledge) is if it might be a vessel for other types of data communication other than the simple "Play/Stop/Next" commands sent from the remote control.
My source (whom I trust to be forthright and honest) has mentioned a couple of interesting ideas that I do not take any responsibility for if they are totally false or totally whack:
1) When a defective PSP unit is returned to Sony (one with damaged firmware). A special dongle is attached to the remote control port to reflash the firmware with a proper working image. If we can only find the command sequence that the little dongle sends....Marcus has already been pretty successfull in sniffing the commands sent by the remote itself.
2) The port is purported to contain a "debugging" function. I don't have any more info on that and no way of finding out if the debugging goes on through a PS2Tool or whatnot.
3) A cable connects from the PSP's Remote Control port to a development unit for UMD emulation, power, and again debugging. Is this really plausible? I don't know. Full UMD emulation through that little port? Seems fishy. Wouldn't the USB port be a little bit more suited for this kind of work? But then again this might be a slight-of-hand trick meant to keep prying minds away from Sony's little secret...
I know there's not much to look at unless we can get access to say the "firmware reflashing dongle" (if it even exists!), but I just wanted to raise this topic up from the dead.
Call me skeptic on all of this but I just wanted to get some feedback on this little bit of info that I received. I hate being that person that just throws out "ideas" and never does anything...so while I "throw" this idea out I'm going to go see what I can start digging up (if anything).
I would appreciate any ideas/thoughts.
PSP Long term vision
It seems to me that this interface on the PSP is intended for general purpose serial communications for the logical reason of the psp longterm vision and physical layout of the psp.
If you look at the psp, the usb interface is on the top of the unit. I just cant see hooking up devices to the unit on the top as being the best place for all uses. If you look at the logic 3 keyboard interface that is due to be released soon http://www.gizmodo.com/gadgets/home-ent ... 034915.php you can see what this device may become soon.
This device uses a keyboard/cover for the psp that uses a wire extending from the top of the unit down to the hinging point on the bottom of the screen. I would think that a keyboard could be better integrated using the remote control port because the the packaging aspect. Why wants a wire routed from the top of the unit down the back to the bottom?
Also, look at the long term vision of this unit. You have the convergence of wireless networking (internet), portablity and powerfull processors with multimedia capablity. If you add in remote destop this unit becomes the client to your pc's server. You dont need portable mass storage if you can access the mass storage on you existing computer. Plus you dont need to write local compatible apps like "PSP Office" etc. You just need to write a remote desktop client, or better yet using open source VNC. Then write a streaming media client for your digitial media that is already on your PC.
Look how Sony canned the Clie. Right now they have no personal organizer, yet they have a device that is more than capable of performing this function.
Sony already has a hardcase/battery pack. If you put a keyboard (which is the only thing the PSP doesn't have) on the opposite side of the flip down case, you have a palmtop computer with enough juice to survive a transatlantic flight. You just need to plug it via the bottom mounted power and remote control interface. Then getting to the UMD is cake and you can easily remove the PSP from the assembly and put it in your pocket.
It is just a natural evolution of creative thinking by people like ourselves that will extend this device into uncharted waters. The one thing that is missing that I am sure people will want is access to cellular voice/network. For that I would assume a top mounted USB attached unit with integrated antenna.
Sorry to be non technically oriented towards this post but I wanted to inject some logic/vision (or pipe dream) into the thread.
PS. The other thing that this unit doesn't have is bluetooth, and I guess you could have a wireless bluetooth adapter hook into the USB port and use wireless portable keyboards as well, as well as mice etc. However the cabablity of the remote control port I believe is there to at least provide wired keyboard control which would be cheaper and more secure.
If you look at the psp, the usb interface is on the top of the unit. I just cant see hooking up devices to the unit on the top as being the best place for all uses. If you look at the logic 3 keyboard interface that is due to be released soon http://www.gizmodo.com/gadgets/home-ent ... 034915.php you can see what this device may become soon.
This device uses a keyboard/cover for the psp that uses a wire extending from the top of the unit down to the hinging point on the bottom of the screen. I would think that a keyboard could be better integrated using the remote control port because the the packaging aspect. Why wants a wire routed from the top of the unit down the back to the bottom?
Also, look at the long term vision of this unit. You have the convergence of wireless networking (internet), portablity and powerfull processors with multimedia capablity. If you add in remote destop this unit becomes the client to your pc's server. You dont need portable mass storage if you can access the mass storage on you existing computer. Plus you dont need to write local compatible apps like "PSP Office" etc. You just need to write a remote desktop client, or better yet using open source VNC. Then write a streaming media client for your digitial media that is already on your PC.
Look how Sony canned the Clie. Right now they have no personal organizer, yet they have a device that is more than capable of performing this function.
Sony already has a hardcase/battery pack. If you put a keyboard (which is the only thing the PSP doesn't have) on the opposite side of the flip down case, you have a palmtop computer with enough juice to survive a transatlantic flight. You just need to plug it via the bottom mounted power and remote control interface. Then getting to the UMD is cake and you can easily remove the PSP from the assembly and put it in your pocket.
It is just a natural evolution of creative thinking by people like ourselves that will extend this device into uncharted waters. The one thing that is missing that I am sure people will want is access to cellular voice/network. For that I would assume a top mounted USB attached unit with integrated antenna.
Sorry to be non technically oriented towards this post but I wanted to inject some logic/vision (or pipe dream) into the thread.
PS. The other thing that this unit doesn't have is bluetooth, and I guess you could have a wireless bluetooth adapter hook into the USB port and use wireless portable keyboards as well, as well as mice etc. However the cabablity of the remote control port I believe is there to at least provide wired keyboard control which would be cheaper and more secure.
OK, I have a few more questions about the remote control port, from discussions about firmare re-flashing using this port.
1/ It is a safe bet to assume that a serial debug/console mode is integrated in this port (through the RS-232 protocol). Provided we can figure out how to enable the actual debug/console, we will still need to figure out a convenient way to plug that port into a PC.
As a proof of concept, has anybody tried to connect this port through a serial line driver (MAX 232A/233A) to see if they were able to receive/send the Remote Control commands? (I would do that myself, but I don't have a PSP...)
2/ Has anybody analysed the path of the remote control ports on the PSP's PCB to find out to which IC's/pin # they were connected? This would tell us a lot about the actual capabilities of this port. Especially, is it possible that the audio port could be used for something else than audio (eg: high speed data input for UMD emulation and other things)?
3/ If the re-flashing dongle exists and Sony do their job well, it will be very difficult to get our hands on it... On the other hand, getting access to a PSP with the Remote-port development cable might be slightly easier. Has anybody had a chance to get access to that cable and could tell us more about the pins used?
4/ From what I understand, the development cable is supposed to power the PSP too through the remote port? Is there really a pin on that remote port that looks like it could be used for input power? If not, then the assumption that the PSP's Remote Control port alone sports UMD emulation, power and debugging might have to be reviewed...
1/ It is a safe bet to assume that a serial debug/console mode is integrated in this port (through the RS-232 protocol). Provided we can figure out how to enable the actual debug/console, we will still need to figure out a convenient way to plug that port into a PC.
As a proof of concept, has anybody tried to connect this port through a serial line driver (MAX 232A/233A) to see if they were able to receive/send the Remote Control commands? (I would do that myself, but I don't have a PSP...)
2/ Has anybody analysed the path of the remote control ports on the PSP's PCB to find out to which IC's/pin # they were connected? This would tell us a lot about the actual capabilities of this port. Especially, is it possible that the audio port could be used for something else than audio (eg: high speed data input for UMD emulation and other things)?
3/ If the re-flashing dongle exists and Sony do their job well, it will be very difficult to get our hands on it... On the other hand, getting access to a PSP with the Remote-port development cable might be slightly easier. Has anybody had a chance to get access to that cable and could tell us more about the pins used?
4/ From what I understand, the development cable is supposed to power the PSP too through the remote port? Is there really a pin on that remote port that looks like it could be used for input power? If not, then the assumption that the PSP's Remote Control port alone sports UMD emulation, power and debugging might have to be reviewed...
digihoe, that's a good idea actually.... the only problem with it is that if Sony is contrived enough to make the debug mode require the remote port, then they're not the kind of guys who would have the remote that came with the PSP able to send the message that would boot up the debug mode.
However, if we send a barrage of random data at the PSP thru the remote port, we might get something
However, if we send a barrage of random data at the PSP thru the remote port, we might get something
PSP port
For the tests we did I think we took a clear idea that it's a low-speed serial port, or if you want we can assume it could go to a maximum of 115200 bauds (the maximum serial port standard, if I'm not wrong). So It's not possible to use it for high data rates, such video or something similar, but it's situable for low speed devices such as keyboards or things like that. It also seems reasonable that can be a debug and "first flash" or "emergency flash" port for firmware (slow but robust), but to do all this kind of things we need to know wich protocol is used, and it could be anything...
I was thinking on plugging something there to do some tests, but I didn't have time yet, and it uses quite strange voltage values (0-2'5V). The next step I will try is to plug a microcontroller (perhaps PIC) with low voltage power supply (they can use even 2V) and do some tests, but I still don't know when. :P
I was thinking on plugging something there to do some tests, but I didn't have time yet, and it uses quite strange voltage values (0-2'5V). The next step I will try is to plug a microcontroller (perhaps PIC) with low voltage power supply (they can use even 2V) and do some tests, but I still don't know when. :P
Re: PSP port
You're forgetting that these pins are almost certainly reconfigurable, so the protocol used on the pins can be changed, allowing much higher transfer rates.Ihsan wrote:For the tests we did I think we took a clear idea that it's a low-speed serial port, or if you want we can assume it could go to a maximum of 115200 bauds (the maximum serial port standard, if I'm not wrong). So It's not possible to use it for high data rates, such video or something similar, but it's situable for low speed devices such as keyboards or things like that. It also seems reasonable that can be a debug and "first flash" or "emergency flash" port for firmware (slow but robust), but to do all this kind of things we need to know wich protocol is used, and it could be anything...
I was thinking on plugging something there to do some tests, but I didn't have time yet, and it uses quite strange voltage values (0-2'5V). The next step I will try is to plug a microcontroller (perhaps PIC) with low voltage power supply (they can use even 2V) and do some tests, but I still don't know when. :P
Live free, prosper, and under my rule.
I too would think that pin 3 and 6 are used for RS-232 and RS-232 only. The logic behind that is that developers seem to use that port for low level system access (debug/console) and the last thing you want then is to sever this kind of connection for one reason or another.
Now a serial connection only needs 3 wires, and the remote port has 6. Assuming that a 4th pin is used to power external device, this leaves us with 2 pins that could be used for high speed tranfer (and that's without counting the possibility of overriding the audio port for that too).
From what I have read, the use for pins 1 & 4 has not been formally identified. Could these be used for something like S/PDIF (Sony co created that protocol, so they might as well use it)? That would give us our high speed data transfer for firmware flashing and (possibly) UMD emulation on the PSP development system...
Now a serial connection only needs 3 wires, and the remote port has 6. Assuming that a 4th pin is used to power external device, this leaves us with 2 pins that could be used for high speed tranfer (and that's without counting the possibility of overriding the audio port for that too).
From what I have read, the use for pins 1 & 4 has not been formally identified. Could these be used for something like S/PDIF (Sony co created that protocol, so they might as well use it)? That would give us our high speed data transfer for firmware flashing and (possibly) UMD emulation on the PSP development system...
-
ForumsAreGay
- Posts: 2
- Joined: Wed May 04, 2005 5:09 am
A lot of us have heard that rumour... This doesn't look too far fetched a possibility (a lot of hardware these day has failsafe mode to allow reflashing of the firmware of a failed unit), but it is probably prudent to leave this as what it is: a rumour.
Now, I've continued trying to guess what the remote port capabilities really are, and I now believe that the last 2 unidentified pins (#1 & 4 on this page) could be the SDA and SCL signals of an I2C connection.
This would make sense with the fact that:
o I2C is a bidirectional bus that only requires 2 signal lines (apart from GND, which we already have) and can go up to 3.4 Mbits (section 1.2 of the I2C specifications). That rate, or lower, would go well to transfer firmware data, or even data from a simlated UMD unit, as is supposedly the case with the PSP development platform
o The MIPS CPU has a wide range of IO capabilities, including UART and I2C, and, according to this document from Sony, the I/O voltage of the MIPS CPU is 2.5V, which is the voltage that is being observed on the remote control port. This tend to indicate that these lines could go directly to the CPU => convenient for a failsafe/debug mode
o Part of the remote control port has already been identified as an UART, and in the list of modules that have been identified from the 1.0 flash dump, we find 'uart4.prx', so it is safe to assume that the uart4 module handles the serial part of the remote control port.
But In the module list, we also find an 'i2c.prx'. We therefore have i2c functions embedded in the PSP. Wouldn't it be possible that these go to the remote control port too?
Now, the only flaw with that reasoning is that if the remote port is handled by modules in the flash, and the flash goes into brick mode, recovery could become a bit of a headache for Sony...
Now, I've continued trying to guess what the remote port capabilities really are, and I now believe that the last 2 unidentified pins (#1 & 4 on this page) could be the SDA and SCL signals of an I2C connection.
This would make sense with the fact that:
o I2C is a bidirectional bus that only requires 2 signal lines (apart from GND, which we already have) and can go up to 3.4 Mbits (section 1.2 of the I2C specifications). That rate, or lower, would go well to transfer firmware data, or even data from a simlated UMD unit, as is supposedly the case with the PSP development platform
o The MIPS CPU has a wide range of IO capabilities, including UART and I2C, and, according to this document from Sony, the I/O voltage of the MIPS CPU is 2.5V, which is the voltage that is being observed on the remote control port. This tend to indicate that these lines could go directly to the CPU => convenient for a failsafe/debug mode
o Part of the remote control port has already been identified as an UART, and in the list of modules that have been identified from the 1.0 flash dump, we find 'uart4.prx', so it is safe to assume that the uart4 module handles the serial part of the remote control port.
But In the module list, we also find an 'i2c.prx'. We therefore have i2c functions embedded in the PSP. Wouldn't it be possible that these go to the remote control port too?
Now, the only flaw with that reasoning is that if the remote port is handled by modules in the flash, and the flash goes into brick mode, recovery could become a bit of a headache for Sony...
Uart4.prx drives a serial port not related to the remote. It's used as a debug console, so it's possibly tied to the CPU but not exposed on consumer PSPs.
Checking...
The "HP remote" driver doesn't appear to use the I2C driver either. So far I've found that the clock generator and the WM8750 audio codec are the only devices that use I2C.
Checking...
The "HP remote" driver doesn't appear to use the I2C driver either. So far I've found that the clock generator and the WM8750 audio codec are the only devices that use I2C.
-
StrontiumDog
- Posts: 55
- Joined: Wed Jun 01, 2005 1:41 pm
- Location: Somewhere in the South Pacific
It looks to me like the Remote is parasitically powered from the PSP's TX Line.
The logs support this.
All the remote needs is a cap of sufficient capacity to hold power during the low transistions at 4800bps (not hard).
Then when the PSP detects an error, it actually "Powers Down" the remote, detects that power has gone (because the micro fails to hold up its TX line) and then re-applies power.
Why I say this.
There is also a very long time in you log here between the last F0 from the remote and the reported "Framing Error (BRK?)" It looks like the error was reported when the line returned to a high (marking) state. Just a guess.
If so, the PSP held the line low for over a second, more than long enough to discharge the power caps on the remote. Also, it would be interesting if this time gets longer on subsequent comms flubs (ie a longer time to discharge the caps) If it did id guess it would be double the duration each time. (ie, first reset 1 second, 2nd 2 seconds, 3rd 4 seconds).
For a self powered device, it would just detect the Break Condition, and perform a communications reset. The assumption here is a self powered device is being operated by a skilled technician.
As for the mysterious Pins,
Dont forget Sony have mentioned several times they will release a hadphone commander with a microphone, the PSP will need a mono audio input for that, one of the pins would be for that.
see
http://www.us.playstation.com/pressreleases.aspx?id=207
And before people jump up and down and say "it would be USB" thats just crazy talk, a mono 8/16 bit A/D with direct analog input would be far cheaper and easier to implement than a USB Mic, and would also require far less power to operate. They didnt use USB to output audio did they, for the same reason.
So at least one of the extra pins would be for that, and id guess 2 would be required for that (mic power, mic in). Mic power doesnt have to have much drive, as a standard electret style mic has a max load of about 0.5mA at 2.5V
You also wouldnt want to tap on mic power because if you induced noise onto it, your mic input would be noisy.
So my guess is your other 2 pins are the mic input, and when there is no mic connected, they are tied together.
Just a guess though, because you havent mentioned mic at all (which isnt surprising becuase none of us have a mic headset to play with)
The logs support this.
All the remote needs is a cap of sufficient capacity to hold power during the low transistions at 4800bps (not hard).
Then when the PSP detects an error, it actually "Powers Down" the remote, detects that power has gone (because the micro fails to hold up its TX line) and then re-applies power.
Why I say this.
Remote flubs the comms. PSP says Hmm, dont like you. Powers it down by dropping its TX Line for a period it knows is long enough to discharge the power cap on the remote.mc wrote:
Cold start
=======
Pin6 00:00:00.557 : f0
Pin6 00:00:00.617 : f0
Pin6 00:00:00.677 : f0
Pin6 00:00:00.737 : f0
Pin6 00:00:00.796 : f0
Pin6 00:00:00.856 : f0
Pin3 00:00:00.870 : f8
Pin6 00:00:00.876 : fd 80 01 01 01 81 fe
Pin3 00:00:00.906 : fa
Pin6 00:00:00.911 : f0
Pin3 00:00:00.916 : f8
Pin6 00:00:00.921 : fd 83 01 a8 00 47 6d fe
Pin6 00:00:01.001 : f0
Pin6 00:00:01.061 : f0
Pin3 00:00:01.080 : f0
There is also a very long time in you log here between the last F0 from the remote and the reported "Framing Error (BRK?)" It looks like the error was reported when the line returned to a high (marking) state. Just a guess.
If so, the PSP held the line low for over a second, more than long enough to discharge the power caps on the remote. Also, it would be interesting if this time gets longer on subsequent comms flubs (ie a longer time to discharge the caps) If it did id guess it would be double the duration each time. (ie, first reset 1 second, 2nd 2 seconds, 3rd 4 seconds).
Power would then be re-applied clean to the remote, which then goes through a cold restart with a clean power transistion (the best reset you can get).mc wrote: Pin3 00:00:02.430 Framing error (BRK?)
Pin6 00:00:02.430 Framing error (BRK?)
This time it didnt flub the comms, and the PSP was happy.mc wrote: Pin6 00:00:02.555 : f0
Pin3 00:00:02.567 : f8
Pin6 00:00:02.571 : fd 80 01 01 01 81 fe
Pin3 00:00:02.600 : fa
Pin6 00:00:02.605 : f0
Pin3 00:00:02.617 : f8
Pin6 00:00:02.620 : fd 83 01 a8 00 47 6d fe
Pin3 00:00:02.650 : fb f0
Pin6 00:00:02.655 : f8
Pin3 00:00:02.667 : fd 03 01 02 fe
Pin6 00:00:02.680 : fb
Pin3 00:00:02.683 : f0
Pin6 00:00:02.685 : f0
Pin3 00:00:02.700 : f8
Pin6 00:00:02.705 : fd 84 00 00 84 fe
Pin3 00:00:02.719 : fa f0
Pin6 00:00:02.725 : f8
Pin3 00:00:02.733 : fd 02 00 02 fe
Pin6 00:00:02.745 : fa
For a self powered device, it would just detect the Break Condition, and perform a communications reset. The assumption here is a self powered device is being operated by a skilled technician.
As for the mysterious Pins,
Dont forget Sony have mentioned several times they will release a hadphone commander with a microphone, the PSP will need a mono audio input for that, one of the pins would be for that.
see
http://www.us.playstation.com/pressreleases.aspx?id=207
And before people jump up and down and say "it would be USB" thats just crazy talk, a mono 8/16 bit A/D with direct analog input would be far cheaper and easier to implement than a USB Mic, and would also require far less power to operate. They didnt use USB to output audio did they, for the same reason.
So at least one of the extra pins would be for that, and id guess 2 would be required for that (mic power, mic in). Mic power doesnt have to have much drive, as a standard electret style mic has a max load of about 0.5mA at 2.5V
You also wouldnt want to tap on mic power because if you induced noise onto it, your mic input would be noisy.
So my guess is your other 2 pins are the mic input, and when there is no mic connected, they are tied together.
Just a guess though, because you havent mentioned mic at all (which isnt surprising becuase none of us have a mic headset to play with)
That's interesting, because if the microphone is using I2C (which is something I also considered in above post, because I am aware of the planned microphone extension), you'd probably want the audio codec to tap into the I2C data to compress raw digitital input audio.mrbrown wrote:So far I've found that the clock generator and the WM8750 audio codec are the only devices that use I2C.
Of course this assumes that Analog->Digital conversion is done within the mike device rather than inside the PSP, but I don't see that as much of a problem in modern day devices.
Now, don't get me wrong: I'm not trying to stubbornly defend some pet theory of mine here. It just looks looks to me like the wise thing to do if I were Sony because:
I2C pretty much comes with the CPU => footprint on both hardware and firmware is very low, which is something very desirable for when you go embedded.
I2C is very versatile => you can plug other devices than a simple mike, and you could possibly use it to restore/QA a faulty unit without having to open it.
On another subject, there's something I don't get in mrbrown's post. Until now I had always assumed that the PRX modules that have been dumped from 1.0 are encrypted and thus prevent us from figuring out what they do. Did I miss something here?
-
StrontiumDog
- Posts: 55
- Joined: Wed Jun 01, 2005 1:41 pm
- Location: Somewhere in the South Pacific
To Quote:>NIL: wrote:That's interesting, because if the microphone is using I2C (which is something I also considered in above post, because I am aware of the planned microphone extension), you'd probably want the audio codec to tap into the I2C data to compress raw digitital input audio.mrbrown wrote:So far I've found that the clock generator and the WM8750 audio codec are the only devices that use I2C.
http://www.wolfsonmicro.com/products/di ... lash=false
http://www.wolfsonmicro.com/products/di ... lash=falseThe WM8750L is a low power, high quality stereo codec designed for portable digital audio applications.
The device integrates complete interfaces to stereo or mono microphones and a stereo headphone.
If the PSP uses this chip (and im assuming it does, cause you referenced it), why wouldnt they use its analog mic input capability, it just doesnt make sense for it not to be analog, cheap, low footprint, they already have the A/D hardware in place, etc.
Its interface is I2C for things like volume control, sample rate setting etc. It does not send audio over I2C. I2C is just not a good interface for diital audio transmission. The WM8750 has a dedicated digital audio interface (Bit CLK, LRClk for ADC and DAC, Data for ADC and DAC) that will presumably go directly to the DSP. For the lay person, think of it sort of like a custom version of AC97, but with audio data seperate from the control stream. (its not really anything like AC97, but think of it like AC97 at a block level and you will be on the right track).
-
Guest
There is a PRX file in the flash that is known specifically by that chips part number. I believe I have also seen some other article referencing this chip being used. So take that as some corroboartion.StrontiumDog wrote: If the PSP uses this chip (and im assuming it does, cause you referenced it), why wouldnt they use its analog mic input capability, it just doesnt make sense for it not to be analog, cheap, low footprint, they already have the A/D hardware in place, etc.
I have a ripped-apart PSP with mainboards...maybe I should take some pics and post them.... eventually...