From: <iku...@ya...> - 2009-07-07 15:36:24
|
Check your monitor's documentation and the USB 2.0 spec for asynchronous transfers. Differences in how the monitor responds for supposedly-identical command sets are generally issues with the monitor or communication, not the command sets. If you look at the pyusb source code, it's pretty much a simple wrapper for libusb. That is, there's no real difference (except convenience in language choice) between programming a driver using pyusb and programming one using libusb. That being said, I'm not entirely sure that pyusb includes support for the asynchronous commands... and it was a fairly recent addition to libusb as well. There's an outside chance that there's a bug in the asynch code, but it's more likely there's a difference between the way the monitor handles asynchronous vs. synchronous input Also try isolating the particular sections of the code where the difference happens. The file you sent is long, has no comments, and has very few print statements. If you're debugging, add in lots more prints, preferably showing the hex code for the transfers sent to & from the monitor at each write / read command. Then compare those hex codes to each other for the sync and async versions - and compare both to the USB spec and the programmer's manual for the monitor. -Sarah --- On Mon, 7/6/09, Scott Sibley <sis...@gm...> wrote: From: Scott Sibley <sis...@gm...> Subject: [Pyusb-users] Hoping for suggestions - libusb-1.0 related To: pyu...@li... Date: Monday, July 6, 2009, 8:04 PM This isn't entirely pyusb related, but it could possibly affect the future of pyusb. I've been working on an LCD controller, with the goal of being able to control multiple, concurrent devices. I needed USB support for my newest LCD, so I began work on that using pyusb-0.1. However, it became clear pretty quickly that I needed an asynchronous solution, so I set out to work on this wielding ctypes and a fresh copy of libusb-1.0. I've run into some snags, overcoming most (Python's GIL was getting in the way for instance), but there's this one issue that just won't go away. See, the operations work fine synchronously following the steps below in sequence. We can view asynchronous I/O as a 5 step process: Allocation: allocate a libusb_transfer (This is self.transfer)Filling: populate the libusb_transfer instance with information about the transfer you wish to perform (libusb_fill_bulk_transfer)Submission: ask libusb to submit the transfer (libusb_submit_transfer)Completion handling: examine transfer results in the libusb_transfer structure (libusb_handle_events and libusb_handle_events_timeout)Deallocation: clean up resources (Not shown below)However, when performing these steps asynchronously only a portion of the LCD is filled with pixels. I've been through libusb's debug messages and usbmon's output, and between async and sync there are no differences, except when I look at the LCD for the results. I'm starting to believe that this is just not possible with Python+ctypes, which is why I said this could possibly affect pyusb. I am of course hoping for an answer to this, and having some experience in both Python and libusb I'm hoping maybe you would have one. I've attached some code if you feel up to looking into this. Also, I have a question opened at Stackoverflow here: http://stackoverflow.com/questions/1060305/usb-sync-vs-async-vs-semi-async-partially-answered-now -----Inline Attachment Follows----- ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry -----Inline Attachment Follows----- _______________________________________________ Pyusb-users mailing list Pyu...@li... https://lists.sourceforge.net/lists/listinfo/pyusb-users |