daniel-santos
commented
10 years ago Well first off, your contributions are most welcomed! I haven't played with this in the last few months and there are a lot of issues I've left unresolved. However, you're delving into one of the most important and also tricky areas.
So I'm first presuming that the performance stats you are talking about are with debugging turned off in the config (i.e., the out-of-tree-autoconf.h file). If not, just comment out CONFIG_MCP2210_DEBUG and CONFIG_MCP2210_DEBUG_VERBOSE and we're done here. Either way, I know for certain that performance is not yet optimal, although the framework is in place and being used (tuning of this would be in mcp2210-spi.c between in spi_complete_urb where we set the variable expected_time_usec). Also of note is the module parameter pending_bytes_wait_threshold which appears to be insufficiently documented. When the mcp2210's buffer has at least this many bytes in it, then the driver will delay before communicating again -- the default value is 45. Also, this value is ignored unless the rather stupidly named config option CONFIG_MCP2210_DONT_SUCK_THE_CPU_DRY is enabled. However, it turns out that disabling that parameter may also slow transfers due to taking too much time from the mcp2210 its self.
But moving on to the chip, it turns out that the mcp2210 is just a pre-programmed PIC of some sort (somebody figured out exactly which one, I forget) in a different package. It has an internal 64 byte buffer, but can only rx/tx 60 bytes of data at a time. I forget off-hand if this is a limitation of HID interrupt URBs or just the interface (I'm thinking that it's because it's designed to be HID compatible). So at the USB level, each message is 64 bytes, but that includes a 4 byte header.
The tricky part is figuring out the optimal delay between sending it more data, because each time we communicate with the mcp2210 via USB, it cannot be talking to the SPI device. So what you're seeing is that we send 60 bytes (42 3c 00 00), the maximum that we can and then it tells us that the transfer was started (42 00 00 20) and that no data has been transmitted yet (of course).
So timing is pretty skewed here because outputting debug info greatly impacts throughput. However, at 11265.704937 you see "usb 2-1.3: timer_callback:" -- if this weren't being debugged, there would have been an appreciable delay between this line and the one right before it. Instead, it pretty much fired as soon as we re-enabled interrupts. So for struct mcp2210_cmd_type_spi, pending_unacked is the number of bytes we have sent to the chip and not received an ACK (the 42 xx xx xx that doesn't indicate an error) and pending_bytes is the number of bytes that we have sent and had ACKed, but that the chip has not yet told us it sent and given us the peripheral's response. Why exactly we only send 4 bytes on the next communication I can't precisely recall, either the chip will NAK them (due to insufficient buffer space) or I have made an error. :) So maybe that is one that you can experiment with. In fact, I'm starting to think that it's the former, because I believe that it does not have a separate read & write buffer, so if we sent 60 bytes, when we already knew that it has 60 bytes to process, then we know that it can only take 4 bytes -- definitely something to confirm and document (probably in the README.md).
Let me know what you find out please!
mweal-ed
bogdanul2003
madeintheusb
I am trying to speed up the transfer speeds as they seem to be at lot slower than I expected (4096 bytes in .77 seconds or 43Kbps vs 4-6Mbps) I would expect it to be a couple of orders faster than this. I know some of the problems is due to the overhead on the USB bus. I was wondering if you could point me in the in the right direction to fix this.
The first issue I have found is drivers looks like it is breaking up the transfer rather oddly. It is breaking up large transfers into 60 byte and 4 byte transfers alternately rather than all 60 byte transfers. I can see where spi_submit_prepare restricts it to 60 bytes transfers but have not found where the messages are restricted to 4 byte transfers.
I am developing on ubuntu 14.04 x86_64 the following is a snippet from the syslog.