Date: Sun, 14 Apr 2002 18:07:32 -0700 From: Peter Haight <peterh@sapros.com> To: Andrew Gordon <arg-bsd@arg1.demon.co.uk> Cc: hardware@freebsd.org Subject: Re: Reading from the USB ugen device. Message-ID: <200204150107.g3F17WRg033229@wartch.sapros.com>
next in thread | raw e-mail | index | archive | help
>I don't know anything about coldsync, but here are a few notes about >receiving with the ugen driver. Apologies if I'm telling you stuff that's >obvious or you already know. Your explanations are great. I'm really ignorant on this stuff. >I haven't analysed exactly what happens when you use a buffer shorter than >the transaction size (the devices I've been playing with don't do huge >transfers in one lump). However, there is an obvious ambiguity when the >transaction size turns out to be an exact multiple of the buffer size you >are using: after reading N full buffers, you don't know if the last buffer >was full because there is more data to follow, or if it was full because >the transaction ended there, as for the USB_SET_SHORT_TRANSFER=0 case. >Possibly you get a 0-length read next time, but I suspect that in fact >that the information is lost and you can't tell. This gives me an idea. Here are two short logs of what's happening. They are both with short transfer on, but with the first, I'm always asking for 1024 and with the second, I'm just asking for what I expect the size of the transaction to be: First log: Attempting read(3, 0x8091800, 1024) read 6 bytes Attempting read(3, 0x8091800, 1024) read 22 bytes Attempting read(3, 0x8091800, 1024) read 6 bytes Attempting read(3, 0x8091800, 1024) read 50 bytes Attempting read(3, 0x8091800, 1024) read 6 bytes Attempting read(3, 0x8091800, 1024) read 8 bytes Attempting read(3, 0x8091800, 1024) read 6 bytes Attempting read(3, 0x8091800, 1024) read 34 bytes Attempting read(3, 0x8091800, 1024) read 6 bytes Attempting read(3, 0x8091800, 1024) read 38 bytes Attempting read(3, 0x8091800, 1024) read 6 bytes Attempting read(3, 0x8091800, 1024) read 44 bytes Attempting read(3, 0x8091800, 1024) read 6 bytes Attempting read(3, 0x8091800, 1024) read 49 bytes Attempting read(3, 0x8091800, 1024) read 6 bytes Attempting read(3, 0x8091800, 1024) read 88 bytes Attempting read(3, 0x8091800, 1024) read 6 bytes Attempting read(3, 0x8091800, 1024) read -1 bytes Second Log: Attempting read(3, 0x8091800, 6) read 6 bytes Attempting read(3, 0x8091800, 22) read 22 bytes Attempting read(3, 0x8091800, 6) read 6 bytes Attempting read(3, 0x8091800, 50) read 50 bytes Attempting read(3, 0x8091800, 6) read 6 bytes Attempting read(3, 0x8091800, 8) read 8 bytes Attempting read(3, 0x8091800, 6) read 6 bytes Attempting read(3, 0x8091800, 34) read 34 bytes Attempting read(3, 0x8091800, 6) read 6 bytes Attempting read(3, 0x8091800, 38) read 38 bytes Attempting read(3, 0x8091800, 6) read 6 bytes Attempting read(3, 0x8091800, 44) read 44 bytes Attempting read(3, 0x8091800, 6) read 6 bytes Attempting read(3, 0x8091800, 49) read 49 bytes Attempting read(3, 0x8091800, 6) read 6 bytes Attempting read(3, 0x8091800, 88) read 88 bytes Attempting read(3, 0x8091800, 6) read 6 bytes Attempting read(3, 0x8091800, 64) read 64 bytes From what you told me and a brief look at the USB spec, I'm guessing it isn't a coincidence that it is failing on that read where I'm expecting 64 bytes (the max size of a USB packet payload). I'm guessing that in short read mode, the driver gets a full length packet and is expecting another data packet but it never comes because that's the end of the data, so it doesn't return from the read until it gets a timeout. I'd like to watch the debug messages for the ugen driver, but I'm having trouble getting the debug messages to go. I put 'options UGEN_DEBUG' in my kernel conf file and I recompiled and installed, but when I do a 'nm /modules/ugen.ko | grep ugendebug' that symbol isn't defined and if I try to do an ioctl(USB_SETDEBUG) I get an 'Invalid Argument' error. It turns out that if I do 'nm ugen.o | grep ugendebug' in my kernel compile directory it prints out the symbol, but the kernel module doesn't seem to be getting the option. In fact if I look at opt_usb.h in my kernel compile directory I see '#define UGEN_DEBUG 1', but if I look at 'modules/usr/src/sys/modules/ugen/opt_usb.h' under my kernel compile directory, it is blank. >I had been thinking of adding another mode to ugen where there is a queue >of read/write transactions and you can use select() to pace the creation >of new transactions - as you do with a socket or a tty style device. This >would be quite easy to add to ugen to suit my requirements (maintaining a >smooth stream of smallish (~1Kbyte) transactions in both directions), but >enhancing it to solve your problem of wanting to break a huge transaction >into small pieces (and presumably to start processing those pieces before >the transaction is complete) would be more tricky. Ahh. I'm beginning to understand why he did it. His scenario would go something like this: - write a request to the palm for a list of databases - read the packet header returned from the palm: read(6) - from the packet header, get the length and read that: read(123) I think the problem he was trying to combat was that he thought that the following could happen: - write a request to the palm for a list of databases - read the packet header returned from the palm: read(6) - the ugen driver reads a 129 byte transaction from the USB bus and returns 6 bytes, but deletes the other 123 bytes because it doesn't buffer between reads. - from the packet header, get the length and read that: read(123), but this read would then fail because the rest of that data was wiped after the previous read Is that possible? If it is, I think that it is working without his buffering because the header is sent in a separate transaction from the payload. So when he does that read(6) it is just grabbing the header transaction and the next 123 bytes comes in the next transaction. (These headers and payloads are a protocol on top of USB, not the USB protocol headers and payloads). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204150107.g3F17WRg033229>