This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgPeter,
On Mon, Jan 31, 2011 at 04:46:32PM +0100, Peter Stuge wrote:
> Harald Welte wrote:
> > > 2. when using a usb hub, having a lot of USB traffic, or poor USB
> > > signal quality (I don't know exactly), bulk read timeouts can
> > > occur in host program simtrace/at91sam7/host/main.c line 230:
> > > rc = usb_bulk_read(udev, SIMTRACE_IN_EP, buf, sizeof(buf), 100000);
> >
> > ok, interesting. I think its not really something we need to care
> > about, if it works reliably using good cables/hubs.
>
> The issue is probably with the fact that bulk transfers are used for
> the data.
>
> Bulk transfers have no bound latency, they will be delivered "as soon
> as possible" but this can very well mean indefinite delay on a loaded
> bus. Interrupt transfers and isochronous transfer both have
> guaranteed bus time, the latter are lossy (think UDP) so I'd suggest
> using interrupt transfer if there's a choice.
IIRC interrupt transfers had a size limit, though. The other issue I've
had in a number of projects is that libusb only provides a synchronous
interface, and it is impossible (without custom additional code) to
receive from both a bulk and and interrupt endpoint at the same time.
This is not really an issue with SIMTRACE, but it has made me avoid interrupt
endpoints at all cost when using libusb.
> Programmatically they work very much like bulk so switching over
> should be simple.
yes, it should be simple.
> Oh, and in host programs please don't use the old libusb-0.1 API with
> usb_ functions as it has been deprecated and unmaintained for years,
> please start using the libusb-1.0 API with libusb_ functions instead;
> it fixes bugs, has better performance and is actually being worked
> on. :)
I'm happy for anyone who has time to update the program. I'm only familiar
with the old API and have thus used it again to quickly get something going.
the entire simtrace stuff was just a quick hack to debug STK stuff, where the
latter being the 'real' work that needed to be done.
Regards,
Harald
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)