On 15 October 2015 at 15:00, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > A: No. > Q: Should I include quotations after my reply? > > http://daringfireball.net/2007/07/on_top > > On Thu, Oct 15, 2015 at 02:56:48PM +0100, John Tapsell wrote: >> Hi Greg, >> >> I'm trying to write a driver for this specific usb-to-i2c chip >> (mcp2221). It only offers an In and Out Interrupt Endpoint. To do a >> single i2c read I need to: >> >> 1. Send a packet saying "I want to read from i2c" >> 2. Wait for a reply saying 'okay'. >> 3. Send another packet saying "Please now send me the data that you read" >> 4. Wait for that reply. >> >> This means a delay of 2x8ms = 16ms to get a single bit of data. For >> the specific case that I want to use the chip for, this means I'm >> reading from my i2c sensor at 62 hz. I'd really like to do better if >> it at all possible. >> >> Any suggestions? > > For a horrid protocol like this, no, there isn't any way to make it go > faster, sorry. That is designed in such a way to make it the worst > possible thing for a USB system, go kick the person who designed such a > thing (hint, they have no idea how USB works...) > > I strongly suggest going and getting a different sensor chip, don't > encourage such behaviour by actually buying their hardware. > > sorry, > > greg k-h Thank you very much. I did have one wacky idea. I'm sure it's stupid, but here it is: Is it at all possible that there's a bug in the linux usb code where a bInterval value of 1ms is being converted into microframes (8 microframes) but then because it's a full speed device it's then incorrectly read as an 8ms delay? I did have a look into the code, but got thoroughly lost. Any pointers on how I could check my wacky theory? I'm just wondering where this 8ms delay comes from. Thanks, John -- 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
