How to do unpredictable USB input

the link on the page you linked to gives me 0.12

Whoops. How stupid of me. That’s because I’m concentrating on version 0.13 at the moment.

Thank you for reminding me, Frank, and I apologise for the confusion I have caused. Indeed, my site does have version 0.12 on it at the moment.

0.12 seems to work OK with my Canon Digital Ixus 70, both on my Iyonix and my Pi.

Wow again. More good news. Thanks for the feedback!

It seems that the only device failing at the moment is a Benq DC C800 that I have here, which barfs (puts up “PRINTER ERROR” on its LCD) as soon as I ask it how many objects it has in its root directory. A strange beast. I don’t actually know if it works with Windows when set as a PTP/MTP device. I guess I really should try it, with a USB analyser attached.

Just need an easy way to find the device now.

What exactly do you mean? I thought finding devices was easy with the Castle stack.

Then the only mystery remaining is isochronous transfers.

That really would be good. You would earn a bounty for that – not to mention gratitude from lots of people!

I found identifying the device and locating the endpoints the biggest obstacle when first starting. The rest is just like reading/writing to a file and sending configuration commands. All normal stuff. I’ve tried creating the descriptor tree myself and tried letting the OS do it for me but it seems so, for want of a better word, ugly. When I write a simple terminal program there’s twice as much code involved in finding the endpoints than the rest of the program. Not good for tempting people to give it a go.

Well, I just managed to transfer two files to my phone.

I’m not by any means all the way there yet; the file has to be smaller than 32756 bytes, because it has to transfer all in one chunk. Still, having got this far, I can extend the code I have. It does chunked reads; it will do chunked writes too, before long.

My Huawei Vodafone 736 is a bit strange. It is a mass storage device, doesn’t get mounted by RISC OS, does OK in Linux, and Windows I think it uploads software on connection.
I have another case of a USB 2 harddrive that mounts as USB1.
USBInfo shows Product IDE-USB2.0 Bridge but USB spec 1.10 and all the other id fields are 0’s.
Is there any way to modify what USB finds?

I haven’t found a way to change what usb finds but do either appear in *usbdevices? If so post

*usbdevinfo
*usbconfinfo

(would have been nicer if they returned the standard descriptor field names and values but that’s another story – field offsets/size would be handy too for BASIC programming)

If you can use linux you may be able to find out similar information for the devices. It would be interesting to see if there was a difference.

Colin,
The first Linux distro I tried offered less info than RISC OS but I’m sure I can find a more comprehensive method with a search.
The cellphone:

Vendor ID : 12D1
Product ID : 101F
Device ID : 0000
Manufacturer : ‘Vodafone Group’
Product : ‘V736’

Interface 0.0 class 8.6:80 ’’
1 OUT Bulk 512 bytes 0 frames
1 IN Bulk 512 bytes 0 frames

Edit: Linux is showing the FS as type iso9660.

Linux is showing the FS as type iso9660.

Looking at SCSISoftUSB your phone should be recognised ok from ‘class 8.6:80’ so maybe the File system is a problem.

I managed to view files on my galaxy note 2, not had too much time to try much else.
I tried it in “photo” mode, and my pandaboard (using RO 5.21) crashed totally when I plugged it in – not so nice!
In mtp mode it didn’t crash RO and as I said your program could see the files on it fine, I navigated around my phone without any issues.

In mtp mode it didn’t crash RO and as I said your program could see the files on it fine, I navigated around my phone without any issues.

Good to hear – thanks for the feedback, Malcolm. Did you try transferring any files from the GN2?

I tried it in “photo” mode, and my pandaboard (using RO 5.21) crashed totally when I plugged it in

I have no idea why that should be. MTP is almost entirely a superset of PTP. That having been said, the descriptors in my GS3 are very different between the two modes.

If you feel like trying it again (shut down all other apps before you try), I would be very interested to see the logfile that !MTP generates. If it actually leaves one when it crashes, that is. !MTP does its logging by open-write-close every time, which makes the logging slow the process down enormously but is more likely to leave some kind of log file behind.

Linux is showing the FS as type iso9660.

That’s the sort of file system that is used on DVDs. CDVDBurn should understand it, I think, but the first challenge is to get the FS presented to it. Steffen?

I’ve tried creating the descriptor tree myself and tried letting the OS do it for me but it seems so, for want of a better word, ugly. When I write a simple terminal program there’s twice as much code involved in finding the endpoints than the rest of the program.

It’s a PITA, I agree. I would have thought that navigating descriptors is more the province of a library than the OS; but, if you can come up with a good API, it’s worthy of consideration.

Colin, The other case of the IDE -USB device.
!USBInfo shows it connected to a yellow EHCI box but it reports a USB 1.1 device and is definitely running at USB1 speed. I plugged into the keyboard USB socket and got the *usbdevinfo 13
USB release : 0110
Device class : 00
Device subclass : 00
Device protocol : 00
Max packet size : 40
Vendor ID : 0000
Product ID : 0000
Device ID : 0000
Manufacturer : ‘GENERIC’
Product : ‘IDE-USB2.0 Bridge’
Serial number : ’’

1. of configs : 1

*usbconfinfo 13
Current config : 1

1. of interfaces : 1
   Config value : 1
   Name : ’’
   Attributes : Bus powered
   Self powered
   Maximum power : 2mA

Interface 0.0 class 8.6:80 ’’
1 IN Bulk 64 bytes 0 frames
2 OUT Bulk 64 bytes 0 frames

“Linux is showing the FS as type iso9660.”
I have been looking back through the USBCDFS posts and tried the driver. It looks like it would work but the device might be uncompliant.
inquiry
Probing 0:0.0
36 byte inquiry: 36 bytes returned OK
Address : 4 5 6 7 8 9 A B C D E F 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 1 2 3 : ASCII Data
00009294 : 05 80 02 02 1F 00 00 00 56 6F 64 61 66 6F 6E 65 4D 61 73 73 20 53 74 6F 72 61 67 65 20 20 20 20 : .€……VodafoneMass Storage 000092B4 : 32 2E 33 31 : 2.31
96 byte inquiry: 36 bytes returned OK
Address : 4 5 6 7 8 9 A B C D E F 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 1 2 3 : ASCII Data
00009294 : 05 80 02 02 1F 00 00 00 56 6F 64 61 66 6F 6E 65 4D 61 73 73 20 53 74 6F 72 61 67 65 20 20 20 20 : .€……VodafoneMass Storage 000092B4 : 32 2E 33 31 : 2.31
512 byte inquiry: Error &201C5 Target error – Illegal request

DADPrint output at
http://homepages.woosh.co.nz/ron.may/V736Debug.txt

Edit: I found that the iso9660 fs is read only, and I believe it’s purpose is to allow Windows to autorun its .inf files etc, so it is of no use to be able to read it anyway. Possibly the windows files then can access the microsd card (fatfs) with some method, but basically, it looks like yet another cellphone timewasting exercise. They continue to disapoint.

I’m starting to see a recurrence of an old problem: my app sits there, potentially for ever, waiting for status (from the bulk IN endpoint) that never arrives. I’ve mainly been using my GS3 phone; unfortunately, although it runs at high speed, my USB analyser is full speed only, so I can’t say categorically whether the phone sends the status packet. It only seems to happen after I’ve sent lots of data via the bulk OUT endpoint.

Colin, is this a problem known to you? Is it solved in recent builds of the Iyonix branch?

I haven’t seen the problem. Are you saying you are not getting data via bulk IN acknowledging data sent via bulk OUT? Has the IN transfer Completed – returning nothing? Has the OUT transfer completed? It would be interesting if you timed out the reply whether you could continue or not. usbtimeout should work for you but if you don’t have the special field fix where you place it in the string is important. It will need to be in this order.

"endpoint/Ninterface/Nalternate/Nreport/Ncontrol,isochronous,bulk,interrupt/Susbtimeout/Nsize/Nnopad/Sshort/S"

Are you saying you are not getting data via bulk IN acknowledging data sent via bulk OUT?

That’s correct, though only sometimes. Any command or data out should be followed by a status in (at least 12 bytes, plus any arguments that are dependent on what went out and whether it succeeded). Mostly it is. I can go up and down directory trees for ages with 100% success; they only involve short writes. Reading files also works OK, no matter how large. Writing a file out always gets status in after the command phase out, but only sometimes after the data phase out.

Has the OUT transfer completed?

Yes: R3 = R4.

Has the IN transfer Completed – returning nothing?

It appears that the IN transfer never completes, in the failure case.

I need to check my code some more (although some of the inconsistent results after writing a file out are after following identical paths through my code), and I need to see whether I get the same results on the BBxM and RPi.

My fault. I didn’t realise that you can’t transfer stuff bigger than the size of the buffer specified when opening the pipe. I had opened the output pipe with a size of 8193, and was trying to send chunks of up to 32768 bytes. I thought the transfers would be automatically broken up into smaller chunks within the stack.

Now I’ve specified a size of 32768 when opening the pipe, and I can transfer chunks of 32768 bytes.

It does rather beg the question of how big a chunk you can send if you don’t specify the size when you open the pipe.

Anyway, the good news is that it’s now possible to write to a device as well as to read from it.

I still have to find the basis of the bug that sometimes believes a double-click is on the wrong item. I haven’t even rationalised the pattern of when it happens, yet.

I’m also surprised that writing an item to a device only sometimes causes an ObjectAdded event to arrive at my app.

Interesting experiments at the SAUG meeting last night.

Success with cameras when logging was turned on, but, with logging turned off, getting the directory information (using “Refresh”) always locked, waiting for input from the camera – but at a different point each time.

I also noticed cases of status not being returned to my app.

I’m sure the device is returning status every time. My bet is that something in the RISC OS USB stack is failing to get the data up to the application.

This is still with RO 5.18 on the Iyonix. Do later versions have any USB stack improvements incorporated?

I’m not so convinced. Mass storage uses DeviceFS and that works. glue.c is its interface to USB. I have a modified USB module that I’m running. How do I turn off logging to see if I have any problems? My suspicion is that a read doesn’t happen because read is already busy ie the transfer complete detection is a problem.

How do I turn off logging to see if I have any problems?

See the !Run file.

You’ve done too good a job with my camera I’m afraid. I can’t make MTP fail. I’ve tried 5.18 and my development version on my Iyonix. My camera uses the OHCI driver – don’t know if that is significant.

the transfer complete detection is a problem.

That would agree with my observations.

Have your changes to the USB stack made it into current development builds of RO?

Did you find a way to apply updated USB modules to a running RO system?

You’ve done too good a job with my camera I’m afraid. I can’t make MTP fail. I’ve tried 5.18 and my development version on my Iyonix.

I’m considering making a public alpha release of MTP. There does appear to be a problem with devices hanging after a while, notably with logging disabled. Apart from that, reading appears to work reliably. Writing works for me; some devices won’t permit it for various reasons, and my recent changes to status handling should make the reasons clear. I’m currently working on Device Properties.

Although it will sometimes fail, and in some of those cases the device has to be power cycled (e.g. opening a camera’s battery compartment), there has been no reported case of data loss. I believe I’ve fixed the bug that caused the wrong item to be selected from the main window.

The DeviceFS and some USBmodule fixes have made it to the latest rom images – maybe not the fixes you want. You are welcome to try the iyonix riscos image I am using tungstendevrom.zip. There shouldn’t be a problem with it but as only I have used it I would play safe and not plug in all your USB drives until you are confident it works. I’d just try it with the cameras attached at first.

If you already softload, the rom just replaces the one in !softload.