How to do unpredictable USB input

but requesting more than 1 byte – non blocking – is robust even if the call only returned 1 byte or indeed 0 bytes

:-(

Unless somebody can show me what I’m doing wrong so this works on a Beagle or can fix whatever in the USB stack is causing the IO Error faults; the simple bottom line is I cannot get this working on a Beagle (xM) and as such I won’t be able to do anything for MIDI on the Beagle.
‘tis a shame. On old-style analogue hardware, the Beagle is much better to look at than the Pi’s composite video…

REM >usbmidi_midisimple v0.01
REM
REM Attempt to read MIDI data on USBMIDI on the Beagle.
REM
REM by Rick Murray, Wednesday, 8th May 2013
REM
REM Test equipment:
REM    Host: Beagle xM with RISC OS 5.19 (25 Feb 2013)
REM                    then RISC OS 5.19 (07 May 2013)
REM  Client: Yamaha PSR E-333 keyboard
REM

ON ERROR PRINT REPORT$+" at "+STR$(ERL) : END

MODE 28

devname$ = "USB8"   : REM Keyboard USB device number
devep% = 2          : REM Input endpoint

REM Open the device.
in% = OPENIN("devices#nopad;noblock;endpoint"+STR$(devep%)+":"+devname$)
REM The nopad/noblock appears to be ignored on the Pi, so...

REM Ensure any problem or Esc pressed closes handle
ON ERROR CLOSE#in% : SOUND 1,0,0,0 : PRINT REPORT$+" at "+STR$(ERL) : END

REM Set the options for noblock the long-winded way
DIM args% 8
args%!0 = &80FF0001 : args%!4 = 0
SYS "OS_Args", 9, in%, args% : REM ioctl

REM Get the USB handle so the following call can work
SYS "DeviceFS_CallDevice", ((1 << 31) + 7), devname$, in% TO ,,,,,usbh%
REM Set the nopad option; it's one of those AND/EOR mask deals like OS_Byte.
SYS "DeviceFS_CallDevice", ((1 << 31) + 8), devname$, usbh%, 1, 1

REM Kick the thing, we're grasping at straws here, really...
SYS "DeviceFS_CallDevice", ((1 << 31) + 5), devname$, in%

REM OS_GBPB buffer
DIM buffy% 4

tick% = 0

REM Crash and burn time :-(
REPEAT
  REM Print how much data is available (Beagle - reports 1023, 1023 always...)
  SYS "DeviceFS_CallDevice", ((1 << 31) + 2), devname$, in% TO ,,,bav%, bfr%
  PRINT "Available = "+STR$(bav%) + ", free = "+STR$(bfr%)

  REM As we're on a Beagle, we'll need to try to read
  REM something to start the process...
  REM USBMIDI commands are four bytes long, so let's read
  REM this. We *KNOW* there is data to come, the keyboard
  REM is sending periodic Active Sense ticks.
  SYS "OS_GBPB", 4, in%, buffy%, 4
  tick% += 1
  PRINT "Tick = "+STR$(tick%)+" Data: "+STR$(buffy%?0)+", ";
  PRINT STR$(buffy%?1)+", "+STR$(buffy%?2)+", "+STR$(buffy%?3)

  REM We don't get here. Damn thing reports IO Error. Grrrr-argh!
UNTIL 0

If I change the noblock flag to 1 (args%!4=1), the program will run about 30 times before failing with IO Error, however the buffer sizes do not change and the data returned is always zero bytes, even when swiping my hand across the keyboard while running the program.

It seems to be time dependent. I added “t% = INKEY(5)” after the buffer printout, and the loop ran exactly once before crashing. I changed the INKEY value to 1 and it ran two (sometimes three) times.

So – as I said – I just can’t get this working on the Beagle…

Looks ok other than OS_GBPB may return 0 bytes when noblock is set

Try changing buffy% to 256 with noblock set and don’t bother reading the buffer size.

count%=0
tick%=0
REPEAT
   SYS "OS_GBPB 4,in%,buffy%,256 TO ,,,r3%

   size%=256-r3%
   ptr%=buffy%
   WHILE size%>0
      CASE count% AND 3 OF
          WHEN 0: tick%+=1;PRINT "Tick = ";STR$(tick%);" Data: ";STR$(?ptr%);
          WHEN 1,2: PRINT ",";STR$(?ptr%);
          WHEN 3:PRINT ",";STR$(?ptr%)
      ENDCASE
      size%-=1
      count%+=1
      ptr%+=1
   ENDWHILE
UNTIL 0

Does it work in a taskwindow?

I don’t hold out much hope for the above code but its worth a try.

I don’t hold out much hope for the above code but its worth a try.

I’m so excited there was nearly a puddle! (um, eww!) I tried the above code in the test framework and got something back; so I altered the main miditest program to read “up to 256 bytes” and then pull the data out of the block that was read. It isn’t perfect (it might miss stuff across block boundaries, so ideally need a function to refill the buffer in those situations) but the most important thing – IT WORKS! Thank you Colin.

And here’s an updated version of miditest. It has not been tested on the Pi (should work?) but it now works on the Beagle. Yay.

http://www.heyrick.co.uk/random/miditest2,ffb

.
.

RISC OS USB, you are so obscure you make my head hurt!

Excellent!

Here’s a bget replacement which will make usb usage a simple matter of open/bget/close as you wanted in an earlier post :-). It took some getting there.

DIM buffy% 256
ptr%=0
end%=0

DEF FNbget
  IF ptr%<end% ptr%+=1:=ptr%?-1
  REPEAT
     SYS "OS_GBPB",4,in%,buffy%,256 TO ,,,end%
  UNTIL end%<>256
  end%=buffy%+256-end%
  ptr%=buffy%+1
=ptr%?-1

You know, I’m really glad I started this thread. It has pulled together contributions from various people, and has made it possible for several of us to do more with USB under RISC OS.

That’s the power of sharing ideas, and talking about things.

That’s the power of sharing ideas, and talking about things.

Yup – I was all but ready to give up on doing this on the Beagle. Now I’m writing code in Zap. (^_^)

However, please, somebody who can stomach Textile markup, please add this to the online documentation so the next hapless guy who happens to stumble across the giant WTF that is the RISC OS USB stack doesn’t go through all this agony!

Rick

I note that in miditest2 you use OS_ServiceCall to list device configurations. Doesn’t that leave allocated RMA memory that you can’t delete? The Docs page I pointed out in an earlier post says:

It is the responsibility of the issuer of this service call to free the memory chunks returned.

But I can see no way of doing that.

Was any progress made with driving the Simtec USB podules – now that RO5 seems to working ok with the RPC?

Was any progress made with driving the Simtec USB podules

What progress are you looking for?

I have a USB multimeter application that I’m working on (the multimeter in question uses a CP2102). It’s in a pretty good state for RO5. I originated it in the days when I was supporting the Simtec stack as well as Castle, so I now have to choose whether to remove all the Simtec stuff or to test it to a releasable standard.

Right now, I’m leaning towards the latter. It will be interesting to switch the Risc PC on again. For the last year or so, it has been nothing more than a monitor stand.

In more general terms, I tend to regard the Simtec stack as being dead. Do you see interest?

Using the ROOL USB stack with the Simtec USB podules running RO5 on a RPc.

Using the ROOL USB stack with the Simtec USB podules running RO5 on a RPc.

You mean a translation layer so that the Simtec podule can present the Castle API?

Do you see enough interest to make it worth the effort?

I note that in miditest2 you use OS_ServiceCall to list device configurations. Doesn’t that leave allocated RMA memory that you can’t delete?

Oh… Okay. So it isn’t a pointer to a static description block. Right-o.

Easily fixed.

But I can see no way of doing that.

Do you mean in my program, or in general?

Just after the OS_ServiceCall are three initialiser assignments then a REPEAT. Around line 230.
After the REPEAT, insert the following:

  REM Remember the block
  origblk% = blk%

Now go down to the matching UNTIL (around line 710) and you’ll see this:

  blk% = next%
UNTIL next% = 0

Just before that, insert the following:

  REM Free the block now
  SYS "OS_Module", 7,, origblk%

(note the two commas in the OS_Module SWI call, the block is passed in R2)

As they used to say where I used to live – sorted! (pronounced like “soh’id”).

I mean’t I didn’t know about os_module 7. But now I do. It would have saved a lot of head scratching.

Not quite “soh’id” early termination of your loops means you won’t delete all blocks.

Well, I did switch on the Risc PC last night. And eventually it booted! Some difficulty in gathering appropriate keyboard and mouse, and getting a display that the nearest monitor can cope with, but eventually succeeded.

Good grief, I’d forgotten how hard it is to use the Simtec stack.

Does anyone know how the Simtec stack behaves when asked to do a bulk IN transfer when the data to be transferred are much bigger than the buffer size? That’s what you would get with PTP, for example, where you have to transfer an entire file – you can’t select parts of it, like you can with a SCSI-over-USB transfer.

There was talk on another thread – about using the Rool stack (year or so ago) – with the Simtec card – thats why I was asking if there was any news update.
Might make it worthwhile getting a USB Podule for the RPC.

Dave have you thought about doing a driver for a two input USB Oscilloscope?

How did you rate the USB to RS232 Serial adaptor? – that Theo found.

Dave H

You mean a translation layer so that the Simtec podule can present the Castle API?

I do not now a thing about USB programming but wouldn’t it be easier/better to write a driver for the chips that are used by Simtec and then forget about their drivers. As I understand we now have low level drivers for Pi, Beagle, Panda (the same?) and Iyonix. One more wouldn’t be that hard (says the guy that only lurks 8-) ).

I do not now a thing about USB programming but wouldn’t it be easier/better to write a driver for the chips that are used by Simtec and then forget about their drivers.

This is how I interpreted the message – to throw away the Simtec drivers and convert an existing RISC OS stack to use the Simtec hardware directly.

Question for somebody who knows – is USB hardware fairly generic (like the multitude of 16650 serial port clones) or are all the chips different to use? I’m just trying to work out why the two flavours of RISC OS that I use (OMAP3/Pi) have completely different stacks with their own specific quirks. Would it not be possible to have one general stack?

Might make it worthwhile getting a USB Podule for the RPC.

I have one – literally a Simtec USB podule, rather than a Unipod – but I have access to a Unipod here at work.

Dave have you thought about doing a driver for a two input USB Oscilloscope?

I’d love to. How much does the oscilloscope cost, and is there a freely available USB protocol specification for it?

How did you rate the USB to RS232 Serial adaptor? – that Theo found.

I did actually reply: “None of the alternatives implements all the lines – although what they do implement is likely to be OK for the majority of applications.”

wouldn’t it be easier/better to write a driver for the chips that are used by Simtec and then forget about their drivers.

That would work, although, since I can’t make head nor tail of the present tangle of code, I’d need help.

But the question remains: is there enough interest to justify it?

Question for somebody who knows – is USB hardware fairly generic (like the multitude of 16650 serial port clones) or are all the chips different to use?

There is a specification that was intended to encourage manufacturers to provide the same interface to their chips. How well it succeeded in that aim, I don’t know. It wouldn’t surprise me if the RPi USB host looks significantly different.

I have a prototype Simtec USB podule. I don’t remember doing anything useful with it.

But the question remains: is there enough interest to justify it?

I think the pragmatic answer to that is, “That depends how interesting you’d find it”.

Replying on my own suggestion. It was already suggested in:
Simtec USB/Unipod support

Sorry about that.

I did get the multimeter application going on the Risc PC last night. It’s time for me to release it. I wonder whether anyone else in the world will actually use it?

Interesting, isn’t it, that the Simtec USB stack doesn’t pad or block. In that respect it’s much easier than the Castle stack. I was amazed that the app’s CPU usage was only about 7%. Not bad, since it has to poll constantly – although not too frequently, since the communication is only at 2400 baud and pauses between readings.

The padding and blocking have little to do with the BSD sources of castles stack. As I see it Padding was added by castle to usb devices because the default state for opening a device with devicefs is to block and castle usb uses devicefs. This means it will never return until the requested number of bytes are fetched or EOF is encountered causing problems with devices that, quite legitimately, send less than the requested bytes. ‘noblock’ which is a devicefs flag makes padding redundant and as I see it padding should always be switched off when ’noblock is set.

So if the special field options worked it would simplify things further.

I’m trying to track down why these flags don’t work in special fields at the moment but its a while since I dabbled in assembler and its like wading through treacle.

EOF should be encountered every time USB sends a packet less than the maximum packet size, because that means the USB transfer has finished. At this point, a read with OS_GBPB should return with R3 equal to the number of bytes that were requested but not returned. This is how OS_GBPB has always been documented. Application programmers should heed the value of R3.

The understanding I have been given is that padding is a bodge to work round code written by programmers who ignored R3 and assumed it would always be zero.

Anyway, that’s history. We can’t rewind time. We should come up with a system that works, is documented correctly, and doesn’t break past code that can’t be fixed (abandonware).

What files contain the code that parses and actions nopad and noblock?

As I see it the transaction can end early but the file isn’t at EOF. eg an endpoint has a 64 byte packet size you os_gbpb 93 bytes the 2nd packet delivered will complete the 93 bytes requested but that isn’t eof its the end of the transaction. If this were not the case streaming would require an open and close on every read.

I’ll come back on the relevant files

Decoding of special field strings is handled by DeviceFS.

It allocates a block containing 1 word for each field in the special field validation string (not the same as special field string) and fills it with values from the special field string in special field validation string order.

The actual decoding is in Special

It’s called from FSystem in the same folder (handlespecial line 2320)

The USB special field validation string is set up when registering the device in USBModule (line 462)