PTP, USB, and the Samsung Galaxy S3

PTP and MTP appear to be thoroughly defined. I can’t point a finger there. And some of your problems (e.g. WMA vs. MP3) are at the highest level – presumably way above the MTP level.

The trouble I’m seeing is at the lowest level: communication (more accurately, lack thereof) over USB.

I’ve also seen a consistent oddity in communication with Bluetooth dongles (though they are full speed only): the USB analyser shows a message coming in from a bulk IN endpoint, but RISC OS doesn’t see it.

The trouble I’m seeing is at the lowest level: communication (more accurately, lack thereof) over USB.

Don’t know whether this is correct or FUD, however…

The USB driver may not be fixable, the jury is still out on this one. There are three key problems:
1) Documentation on the Broadcom USB controller is proprietary and is not made openly available by the Raspberry Pi Foundation.
2) The USB core for the Broadcom SoC was bought from a 3rd party, and we are told that not even Broadcom has full documentation, nor understands the driver.
3) The Foundation has discovered that the controller and its driver expect realtime response from the ARM core, and if Linux’s non-realtime scheduling doesn’t respond in 1 ms, a split transaction USB event can be dropped. Not surprisingly, this occurs regularly and produces lost mouse clicks, stuck keyboard keys, etc..
That’s a pretty nasty combination of problems, and it means that assuming that it’s fixable may not be a safe prediction. We’ll have to wait and see.

For the time being though, USB and networking (which is implemented over USB) have a large catalogue of issues and incompatibilities. All boards have this inherent problem but YMMV on whether the issues bite you, as it depends on exactly what devices you have connnected and what you’re doing with the board.

and:

This USB core had so many problem that we end up making it work only in full speed mode (and not high speed one). As you said split transaction don’t work well (in our case we had seen irq storm that make linux freeze).

[source: http://hardware.slashdot.org/comments.pl?sid=3070945&cid=41120017 ]

It is possible that until the driver is completely sorted out, there may be “quirks”? What tipped me off is you saying a message comes in but RISC OS doesn’t see it, I’d heard of this behaviour before. I thought it had been fixed, but it seems that there are still “issues”; maybe hardware, maybe firmware, maybe software…
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=23544&p=224118
http://www.raspberrypi.org/phpBB3/viewtopic.php?p=218254#p218254

Everything you’ve said there appears to be specific to the Raspberry Pi. I’m seeing this on the Iyonix and BeagleBoard.

The comments on USB on the Pi by Rick above were interesting. I have had a lot of trouble trying to use an SSD on the Pi (via an externally powered hub). The main symptom is that the whole machine freezes (requiring a power cycle) whenever one starts to do a significant amount of transfer. I have tried 3 different 120GB SSDs on the Pi, all of which fail, but all work fine on the ARMini and the Iyonix.

I’ve added a function to refresh the main window from a menu click. This is useful if you take or delete a photo at the camera. http://davehigton.me.uk/Progs/PTP.htm

I have given your new version a try.

On the Rasp Pi (set to strict ARM7), running PTP gives an error box ‘PROCget_object_info: index0 is out of range’. When the box is dismissed PTP remains on the iconbar. It is possible to do DeviceInfo from the menu, and the resulting dialogue is filled in with what looks like sensible data. Any attempt to refresh gives the error box again.

On the BB (ARMini) things are a bit different.
Running PTP gives an error box containing eg.

30 Nov 17:50:38 000 00000000: Error from (unknown): Bad request in “Procedures and functions for Castle USB stack” (error 8491016) at line 660

Dismissing this results in PTP vanishing from the iconbar. However, there is no lock up of the BB – it carries on as normal.

Not sure if any of this adds anything to what you already know.

@ anyone working at getting !PTP to transfer in High Speed mode

For whatever reason, if you put PROCclose_bulkoutpipe on the line before the SYS XOS_GBPB…. (line 1110) that normally crashes, The logging can proceed to show the fact that r2% has returned equal to buf% (in other words no bytes transferred) instead of having to reboot your machine.

Using the Full Speed (USB 1.1) mode with this in place is an interesting comparison, it continues on as it should until the next send is required.
HTH
Edit: The latest download of !PTP now closes cleanly when failing to read the High Speed device, and modifications are not needed.

It does open up the possibility of camera control which I think is done by PTP.

I couldn’t resist trying, and I’ve just taken a couple of pictures with the Coolpix 5200, initiated by my app. I added the most basic form of control: another window with a single “Capture” button.

There is very little control possible via PTP, according to the specification I have, which is the free one from PIMA Inc. dated 2000, predating the official ISO standard which costs over 100 GBP (so I’m not buying that!) Basically it is possible to initiate a single capture (a still photograph) or an open capture (a video or a series of stills).

There is very little control possible via PTP, according to the specification I have,

I’m assuming asking about whether you looked at this is a granny sucking eggs issue:

libptp2: http://libptp.sourceforge.net/

I’ve never had any success porting anything but the very simplest of software to RISC OS.

I am coming to realise more and more that MTP is a superset of PTP, and that’s what I should be chasing. The MTP specification is free. The small downside is that, if you try and treat a PTP device as if it’s MTP, you have to be good at error handling.

I have managed to create and handle an asynchronous event (from the interrupt IN endpoint) today for the first time. Taking a photo causes an ObjectAdded event to be sent; I’ve used this to trigger a redraw of the directory window.

I’m very glad I rewrote the state machine part of the app. It had become unmaintainable; now it looks verbose but it’s dead easy to work on.

If anyone is still interested, I’ve put up a new version (0.09) on my web site.
http://davehigton.me.uk/Progs/PTP.htm

No luck with my Lenovo K1 ideapad (ICS 4.0.3). Configured it to PTP, plugged in and started !PTP: “No Files”, froze my BB-xM. Unplugging even took my mouse pointer down which I don’t see happening that often. Same if re-starting with device plugged in.