I'm developping a card which support 2CAN HS(baudrate up to 1Mb/s)/2 CAN LS and 2 LIN channel. The protocol implemented is the standard CAN layer with normal and extended ID support.
In critical load on USB with several frame to send and receive, it's normal that USB protocol cannot deal with the amount of I/O data... but the libusb should not stop handling, sending, receiving and block on LIBUSB_ERROR_NO_MEM for all submit_transfer call and -5 for handling transfer ! Is this a bug on the libusb/WinUsb or a limitation ? On Wed, Dec 12, 2012 at 9:50 AM, Xiaofan Chen <xiaof...@gmail.com> wrote: > On Wed, Dec 12, 2012 at 4:49 PM, Xiaofan Chen <xiaof...@gmail.com> wrote: >> On Wed, Dec 12, 2012 at 2:11 AM, Tim Roberts <t...@probo.com> wrote: >>> Mohamed HAMZAOUI wrote: >>>> Solution, as pointed out Tim, is to buffer more data in a single >>>> request. It's like nagle algorithm that I will implement, but I think >>>> it is not a good solution in my case. >>>> Firstly, there's several threads that send CAN frames in accordance >>>> with specific conditions... and I should never delay the emission of >>>> any frame. Secondly, A CAN frame has a small size ! >> >> Ah so you are developing a USB to CAN interface device. What >> is the higher level protocol you are using? Are you using >> a customized protocol or a standard protocol? For standard >> higher level protocol, usually there is a method to deal with >> the fragmentation (max 8 bytes in a CAN frame). >> >> More over, what is the baud rate are you running your CAN bus? >> It is only up to 1Mbps anyway and most of them are below 512Kbps. >> >>> Please remember that USB is not an asynchronous bus. Everything is >>> scheduled in advance. No matter how fast you submit your requests, they >>> will all be gathered up and scheduled for the next frame, at the next >>> millisecond boundary. > > A potential solution is to deal with the more time critical in > the USB to CAN device itself (the MCU inside) and then > the host does not need to deal with that since the host > is not running an RTOS after all and USB is a scheduled > bus. > > > -- > Xiaofan > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > libusbx-devel mailing list > libusbx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libusbx-devel ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
