How to do unpredictable USB input

This worked with my Iyonix

This?

Using a RS232 three button serial mouse – no USB required.

Is it possible to connect serial mice to the new machines like the Pi/Beagle etc?

The Pi has no serial port as standard. There are TX/RX available on the GPIO but you’ll need an adapter board, however…

…as with the Beagle (which has a 9 pin serial port), the serial port is not “fully wired”. If you have TX, RX, and GND – where does the mouse draw power from?

It’s the same reason I have not done anything about getting the Psion 3a / Pocketbook interface running – it uses the extra signals on the serial port, but these are rarely present on SoC boards.

That being said – when testing your module I found the keyboard and mouse would reinitialise without a hiccup; on both the Pi and the Beagle.

Yes everything restarts up on my Iyonix too, including usb drives. But then my Iyonix doesn’t have system variables (!system ones amongst them) pointing to a USB device.

But then my Iyonix doesn’t have system variables (!system ones amongst them) pointing to a USB device.

Which is why I said that it needs to be in ROM or patched in extremely early in the boot. ;-)

I think we may be talking in circles though; my most recent point is that the mouse and keyboard reinitialise okay, so I’m not sure that switching to a serial mouse (and what for the keyboard?) is something where the end result justifies doing it at all. As I said, I’m not even sure your module is the problem, it may be RISC OS throwing a wobbly about this and simply RMReInit the supplied USB driver would have caused the same reaction…?

I was just adding to what you said not picking you up on it :-)

If you look in the Obey file for the modules if you replace where I’ve loaded the new modules with rmreinit existing modules You’ll get the same problem – I used an obey file which just rmreinited modules to work out if it was possible to softload them.

Colin: (from July 19th, back on pg10)

for reading
1. open a read endpoint with the special fields set as required
2. read data with an empty buffer with OS_GBPB
3. Intercept the UpCall_BufferFilling upcall which tells you that data is in the buffer and a transfer has been completed by the usb subsystem and data is in the buffer which can be read with osgbpb.

As the changes were not baked into the standard USB module, I twiddled it myself by obtaining the buffer handle and setting the threshold.
It worked, once.
And only once.
Threshold 1023 (buffer is 1024 bytes), read buffer to clear it at init, UpCall 8 then fired. Read buffer (normally) in response to UpCall 8, and parse data. And then…?
Bizarre.
I’ve reverted back to checking it at intervals; I might try checking more frequently (1 or 2cs, see if/how this affects things). It is likely the next release of the module will attempt to provide some sort of timing information, so it would be good to pick up the data as soon as possible.
[the debugging code was still in place – if I read repeatedly on ticks, UpCall 8 is happy to fire, followed by UpCall 9…so it works but not when/how I want it to…go figure!]

On the plus side, I discovered CMHG can have multiple generic-veneer handlers, which makes things nicer.

For others: Attempting to set buffer threshold to fire the moment anything is written into an empty buffer, with the expected aim of being notified when data has arrived, without having to repeatedly GBPB to see if anything is there…

Ah a blast from the past.

It may be due to do with the fact that you are emptying the buffer while data is being inserted. The bufferfill upcall happens during the buffer insertion function. It should work if you empty the buffer from a callback – that’s the way I have tried. It’s not perfect as ideally you want to queue the next read as soon as possible and that won’t happen until you empty the buffer.

Another revival of this thread…

A Bluetooth dongle has an interrupt IN endpoint. There are two kinds of messages received on it:

1. Confirmations of commands sent;
2. Unsolicited messages, e.g. that a remote device is responding to an Inquiry (scan for devices).

The messages vary widely in length. Many are over the maximum packet length for the endpoint (typically 16). Even an Inquiry Result Event message is 17 octets. A Remote Name response is 257 octets. It isn’t possible to know the length of all the incoming messages in advance.

I’ve got a reader function hanging on TickerV. Not surprisingly, I can happen to look at what’s coming in before the last packet of a multi-packet message. The log of the Remote Name response coming in just now shows that I looked at it three times in total.

The good news is that the second octet tells me how many more octets will be in the message.

So what’s my best strategy for reading this stuff? Do I have to read the first two, see how many more octets are in the buffer (there should always be some – I don’t think there are any messages with no octets to follow the length octet), and, if there aren’t that many waiting, store the two until next time round?

Or is there a smarter way?

It is on TickerV, so I assume I can’t block while waiting for the rest to come in.

I’m developing on an Iyonix with 5.20. If there is a better version of the stack that I should be developing with, and I can soft load it, I will.

Actually, I think I’ve answered my own question. I’ve got more testing to do, but it’s late now so I’ll quit while I’m ahead :-)