EtherUSB update - take2

If anyone would like to change the sources EtherUSBUpdate.zip is an update to EtherUSB which cures slow transfers on a pandaboard caused by the last EtherUSB update. Its tested on a pandaboard, pi and beagleboard c4 with ax88772 usb ethernet adapter – see readme file.

Just in case this was missed because of the show I thought I’d post this reminder. I’ll let the thread die gracefully now.

Any chance you could explain the code changes? I notice that a typo has been introduced in the comment on line 389 of c.usb but I can’t see why that line was touched at all. I also think the code in usb_upcall_hook_handler() could be expressed more efficiently (in performance terms):

  _kernel_oserror *usb_upcall_hook_handler(_kernel_swi_regs *r, void *pw)
  {
    switch (r->r[0])
    {
      case 9:
      {
        ...
        break;
      }
      case 15:
      {
        ...
        break;
      }
      default:
      {
        /* do nothing */
      }
    }

UNUSED;
return NULL;
}

  if (r->r[0]==15 && r->r[1]==pipe->file_handle)

&& pipe->direction==USBRead

Also, many thanks, Colin, for your continued efforts to make RISC OS USB better for all. Much appreciated.

Now (cracks whip), get back to explaining yourself in light of the above! ;)

You want me to explain something! hehe.

If you look at the Readme file you’ll see that usb.c reverts to version 1.10 that was already in the CVS before it was changed to 1.11 in my last update. usb.c is just a copy of usb.c version 1.10 so nothing to do with me :-). The symbols were added by me in version 1.11. The problem with fixing bugs is when to stop tinkering.

I have pointed out in the readme file that the event handlers like usb_upcall_hook_handler in etherusb are the wrong type – they should be vector-handlers and not generic-veneers – but they still work to pass on the event.

WPB: will that do sir

Steve: the file handle already implies the direction because the streams are unidirectional, so a test for USBRead would only add processing time.

Yup Dave you are right. I added the clause (and the symbol) because I like to be more explicit about what is happening. Given all the upcalls that DeviceFS and the buffer manager send I didn’t consider it as a candidate for speed optimisation.

Colin, can you tell me if these changes now in the ROM? And for USB ethernet adapters, is it only the ax88772 chipset that’s fixed?

Looking at the cvs sources the changes haven’t been added. The ax88772 fix I submitted was a different issue an I’ve no reason to suppose that the other back ends aren’t ok.