Now ... 0.3ms is too small IMO - doubling to have one job pending - 0.6ms is also too small IMO (the BFL queue design says 20 work items)
So if your queue only allows one work item waiting in it then the code still has to hit a target, that it is going to (sometimes/often?) be late for, due to USB and OS constraints
Thanks for an informative post.
I'm wondering why even use Linux to control chips via SPI? What is the point? I haven't worked on ARM recently, but I did on Xilinx and Microblaze. Going standalone for SPI and I2C access was a
major win in terms of power usage, I didn't even bother to measure speed: it was much faster, but not critical in what I did. Only lwIP is somewhat harder to use than the network interface through sockets.
Did Linux SPI driver had any recent major improvements?
I wonder what bitfury has to say about it, or will he just shut up and smile to avoid disclosing some other, much better, solution to the competition.