Hi, We are developing an ecg (electrocardiogram) application on an OMAP3 device (DM3730 ti). An acquisition board gets the samples in microseconds and sends them to the OMAP board via USB. This acquisition board does a 16KHz sampling which results in ~4000 bytes sent every 8ms to the OMAP board; that gives a necessary throughput of ~0.5MB/s. This acquisition board device is a full-speed one, and the transfers are done in bulk endpoints, so 64B maximum packet size. Given the 1.5 MB/s max _theoretical_ throughput of a full-speed device, it should be enough. And it is if we connect it on an EHCI external Host. The problem comes when we try to use the MUSB OTG configured as host. In that case we get ~300KB/s so the host and the device became desynchronized and a great mess happens :). That could be resolved if we use the EHCI Host Controller with the full-speed device or the MUSB with a high speed device. Unfortunately, we cannot do any of that. So, my suspicions are that we are sending too small packets (64B, so big overhead) and that combines with the interrupt latencies and the degraded performance of a software intensive controller (MUSB vs ECHI, the latter i've read has more functions implemented on HW, i.e queue scheduling). If my assumptions are right (and i'm definitely not an usb expert) we could only resolve the problem by reducing the time spent on the OMAP micro (interrupt service and driver performance) or by increasing the packet size, which would force us, maybe, to use an isochronous inteface instead of a bulk, with the risk of packet lossing. So the question is, given the restraints we face, are there any other options we could consider to reach the .5 MB/s ? Thanks. Pedro Erencia. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
