How to do unpredictable USB input

Just in case anyone hasn’t seen csaa, I’ve announced my MTP app to the public.

http://davehigton.me.uk

In the last couple of evenings I’ve been working on adding support for the Simtec stack. It’s partly working.

The chief snag is that it only works with logging enabled (which makes it desperately slow, even logging to RAM disc). If I disable logging, a window pops up and immediately disappears, giving me no clue as to what went wrong :-(

I keep seeing this same problem: when logging is disabled, things go wrong. Here are the things I’m as sure of as I can be:

• The only thing that logging does is to introduce time delays.

• The state machines are rock solid. Nothing can happen out of sequence.

Having said the latter: is it possible that I’m requesting bulk input so soon after issuing a command that the device hasn’t had time to work out that it needs to send me some data, and that the protocol fails because the device says no data are available?

The only thing that logging does is to introduce time delays.

An idea is to consider dropping in some time delays?

I take it you don’t have the same problem with the RO5 stack which would eliminate a slow device I think. Do you get confirmation that the command has been received by the device or is that just assumed? I’m just wondering whether the command is sitting in a buffer waiting to be sent by the usb stack – don’t know how the simtec stack works.

An idea is to consider dropping in some time delays?

That’s a work-round, not a solution. The trouble with work-rounds like that is that they are not based on an understanding of the problem. Whatever the cause is, it would only have to vary a bit and the work-round wouldn’t work any more.

I take it you don’t have the same problem with the RO5 stack

Yes, I do.

Do you get confirmation that the command has been received by the device or is that just assumed?

Commands can result either in status, or data followed by status. I’m wondering if I ask for a transfer before the device has worked out that it has to send something and therefore the device says there are no data.

An idea is to consider dropping in some time delays?

That’s a work-round, not a solution. The trouble with work-rounds like that is that they are not based on an understanding of the problem.

That’s why I didn’t propose it as a solution. At the moment, we’re looking to figure out why. You say that with logging, it works. Without logging, it goes wrong.
This raises two questions – firstly, as you identified, the logging adds a time delay. Is the time delay the key? Because the other question is “what does the logging actually do?”. If the logging introduces a delay, then it is obviously doing something. Is it using the filesystem at all? Perhaps this, indirectly, is helping it to work? Sure, it is a crazy notion and the time delay is more likely, but it isn’t something to completely rule out until it can be shown working with no logging and time delays.

This would lead on to “how much of a delay, and where?”. When this can be narrowed down, then it will be something to point at and say “is this supposed to happen?”.

I didn’t promote the idea of bunging in delays as a hacky quick-fix, but as a start in diagnosis.

I have a test program here which shows (with blocking input in a taskwindow) that after OS_BPut returns there can be a delay, before the inserted byte is removed from the DeviceFS buffer by the usb subsystem. I think you should try checking if the output buffer is empty or transfer complete before trying to fetch the input data.

I think you should try checking if the output buffer is empty or transfer complete before trying to fetch the input data.

Thanks, Colin. I’ll check tonight, but I seem to recall that I’m already doing that.

A separate question: is it possible for a user-space application to get notification that a USB device has been unplugged?

is it possible for a user-space application to get notification that a USB device has been unplugged?

You may need a veneer module. DeviceFS puts out a message when a device dies with the DeviceFS handle (so you’ll need to get that for your USB devices). Maybe a future incarnation will have some sort of method to raise a Wimp_Message on insertion and removal? That would make life simpler!

And a question from me – when a device is inserted, USB raises a Service Call that provides a pointer to the USB definition block. What is the lifespan of this block? I ask because it isn’t safe to do much of anything in a Service Call handler so I am planning on stashing the address and dealing with it on a callback. Is this safe or is the block likely to have been destroyed by then?

Dave.

I would have thought you would get an error if the device is disconnected. There isn’t an application space notification. You could poll the usb system variables – they dissappear when disconnected. Otherwise I can only think to enumerate the devices again. Both methods sound slow.

Rick.

The block is destroyed when the service call returns so you can’t save it – you could copy it.

The problem of application space notification is the same with sockets. In order to avoid polling you need a module to create application space notification.

In your case Rick you just need a module to set a pollword to tell you that something has changed and then using pollword_nonzero in your wimp program use OS_ServiceCall to see if your device still exists or has just been removed.

I think you can get your program to run automatically when the device is plugged in – though I havn’t tried it.

I would have thought you would get an error if the device is disconnected.

Only if the app is interacting with it. If the app is idle, there are no interactions.

You may need a veneer module. DeviceFS puts out a message when a device dies with the DeviceFS handle (so you’ll need to get that for your USB devices). Maybe a future incarnation will have some sort of method to raise a Wimp_Message on insertion and removal? That would make life simpler!

That’s the “Plan B” that was in my mind. I was hoping I wouldn’t need to write it – but, if I do, I can submit it for inclusion within RISC OS.

I think you should try checking if the output buffer is empty or transfer complete before trying to fetch the input data.

It’s as I thought: the USB bulk write function doesn’t return until either the buffer is empty, or the timeout has been exceeded. The timeout is 10 seconds (1000 cs).

Usbtimeout is milliseconds

If you are using an iyonix and feeling adventurous I’ve worked out how to softload the USB modules. I have an experimental usbdriver module which extends fixes I’ve made in RO 5.21. It would have debugging enabled so it may help tracking down your problem.

I don’t envisage a problem with it – I’ve been using it without problems – but you can’t be too careful. Let me know if you are interested in trying it out.

If you are using an iyonix

Beagle, Pi, etc? Or just Iyonix at the moment?

The timeout is 10 seconds (1000 cs).

Usbtimeout is milliseconds

My timeout is controlled by the monotonic timer, so its units are centiseconds.

If you are using an iyonix and feeling adventurous I’ve worked out how to softload the USB modules. I have an experimental usbdriver module which extends fixes I’ve made in RO 5.21. It would have debugging enabled so it may help tracking down your problem.

I don’t envisage a problem with it – I’ve been using it without problems – but you can’t be too careful. Let me know if you are interested in trying it out.

Yes, please.

Rick.

The reason I said iyonix is because thats the only one I’ve tested the driver on. If you’d like to try it on something else you are welcome to try. I can modify the loader to suit.

I need to kill all the usb modules before installing the new ones so if you do want to try the new version could you tell me if rmreinit etherusb stiffs the machine.

Ok Dave try this USBModule. Please read the readme file before using.

DeviceFS puts out a message when a device dies with the DeviceFS handle

What “message” is this? Is it Service_DeviceDead, Service Call &79, PRM 2-426?

I need to kill all the usb modules before installing the new ones so if you do want to try the new version could you tell me if rmreinit etherusb stiffs the machine.

RaspberryPi Model B (256MiB) with RISC OS 5.19 (28th October 2012).
I have a more recent version of RISC OS, but this card is to one with the dev tools on it.

*RMReInit EtherUSB freezes the machine for about three seconds, then it all comes back exactly as before (tested with *USBDevices and the fact that the keyboard/mouse still work <g>).

In that case if you want to try it I think the usbmodule link above should work. I’d be interested if there were any problems with etherusb.

What “message” is this? Is it Service_DeviceDead, Service Call &79, PRM 2-426?

To answer my own question: yes.

When I unplug a device, there are actually two Service_DeviceDead calls: the first has R3 pointing to a null terminated string such as “USB10”, being the device I unplugged; but the second has R3 = 0. What device does the second service call represent?

Also, for the first call, R2 should be the DeviceFS handle. I’ve not yet been able to equate it with a handle I get for the device, though. Admittedly I haven’t been playing very long yet, but if anyone can offer a quick clarification, I’d appreciate it.