ben-wpan: pings between atben and atusb

[Werner Almesberger]

Thadeu Lima de Souza Cascardo wrote:
> I did some testing in here.

Thanks a lot ! I did some experiments too. Here's the utility
I wrote for them:
http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/tools/usbperf/

Some results:

Device		Direct/hub	Speed	Time per control transfer (ms)
---------------	---------------	-------	------------------------------
Mouse		direct		Low	4.002
Keyboard	direct		Full	1.003
BT dongle	direct		Full	1.012
Ben		hub (HS)	High	0.128
Printer		direct		Full	1.018
Oscilloscope	hub (HS)	Full	0.253
IDBG		hub (HS)	Full	0.250
Hub		direct		High	0.254
ATUSB (SiLabs)	direct		Full	0.999
ATUSB (SiLabs)	hub (HS)	Full	0.210
ATUSB (Atmel)	direct		Full	1.001
ATUSB (Atmel)	hub (HS)	Full	0.253

So the pattern seems to be as follows:
- high-speed devices handle one control transfer per microframe
- for full-speed devices, it depends on how they're connected:
  - directly (using the UHCI), one control transfer per frame
  - via a high-speed hub, ~2 microframes per control transfer

This would be consistent with the pattern you saw, if a hub was
involved in your experiments.

> Unfortunately, I have only EHCI in here right now.

At least a few years ago, EHCI and Full-Speed controller(s) worked
together as follows: if a port was Low-Speed or Full-Speed, the "old"
controller (UHCI, etc.) would take care of it. If the port was High-
Speed, the UHCI's root hub would detach from the port and EHCI would
handle it.

So each High-Speed capable port had access to an UHCI (or similar)
plus an EHCI, each via the respective root hub.

> I get you are using an ATMEGA32U2, right?

Yes, with my own USB stack. The IDBG and the "ATUSB (SiLabs)" above
use an C8051F326 with an earlier version of my stack.

> Yes. But, then, this limit will not only make latency suck, but also the
> throughput.

Yes, unless we can move a lot of data per transfer. Unfortunately,
this currently isn't the case. (We get 1-2 transfers per register
access, about 23 in total for one in-RX -> TX -> back-to-RX cycle.)

Seems that, unless we find a way to get the host controll to do more
than one control transfer per (micro-)frame, I have to rethink the
whole architecture :-(

Any ideas ?

Thanks,
- Werner