Hi Peter, On 2012-07-07, at 5:31 AM, Peter Stuge wrote:
> Kevyn-Alexandre Paré wrote: >> 3- In the callback I need to know what the FD is referring to and >> take action, ex: data is ready to be read for the FD of bulk >> transfer. > > This is a misunderstanding of USB. Maybe... > Data never becomes available. > The application asks the device to send data, when the application > knows that data is supposed to be available in the device. Agree, in my case I send data to an FPGA and I'm always expecting to receive data from it. The application send the data to the device and expect data back. > The device > sends data only when an application asks. Yes > The device has no way to > signal that data is available or not available until the application > asks for data. > > The libusb API deals with synchronous or asynchronous transfers. The > former block until completion or specified timeout, the latter happen > in the background and the specified callback is called on completion > or on error. > > In order to make this work an application must make a small effort to > drive libusb event handling. To run on Windows, there is only one > choice; create a thread which does nothing other than calling > libusb_handle_events_completed() in a loop until there are no more > libusb events to handle (e.g. until your application is exiting). > If Windows is not important then getting the list of fd:s is also an > alternative. When there is an event on any of the fd:s from libusb > then libusb_handle_events() is called to process those events. Windows isn't important. I'm trying to understand how to integrate that example, with my event loop: http://libusbx.sourceforge.net/api-1.0/group__poll.html // initialise libusbx libusb_get_pollfds(ctx) while (user has not requested application exit) { poll(on libusbx file descriptors plus any other event sources of interest, using any timeout that you like) if (poll() indicated activity on libusbx file descriptors) libusb_handle_events_timeout(ctx, &zero_tv); // handle events from other sources here } // clean up and exit This is really close from what I want to do. Hmm I think I just understand my error of comprehension… My loop event doesn't need to manage these fds by it's self but simply call libusb_handle_events(). Then libusb will call my callback function, that I register with libusb_fill_bulk_transfer. In the callback I will manage what I want to do depending on the status?!?! > > >> A A Proposition could be that libusb support nice API to >> distinguish them??: > > No, the fd:s from libusb are opaque. Could you explain what you mean by opaque? > If something happens on any of > them then libusb is called to take care of the event. > > >> Otherwise I will please to push a tested patch. > > Change your program around a little to use libusb the right way. > > > It's a common misunderstanding that devices can communicate with the > application without them being asked to transfer any data. This is not my case, I'm always sending data to the device and then expecting data from it. > > If you want to study USB communication more in depth I recommend > spending a few days with chapter 5, 8, and 9 in the USB 2.0 spec: > http://www.usb.org/developers/docs/usb_20_101111.zip Thx I will definitely read these chapters. - KA > > > //Peter > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > libusbx-devel mailing list > libusbx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libusbx-devel ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
