Could you please open a feature request in SF?
2010/7/10 Diego Jacobi <jacobidi...@gmail.com>:
> 2010/7/10 Wander Lairson <wander.lair...@gmail.com>:
>> 2010/7/9 Diego Jacobi <jacobidi...@gmail.com>:
>>> 2010/7/9 Wander Lairson <wander.lair...@gmail.com>:
>>>> 2010/7/9 Diego Jacobi <jacobidi...@gmail.com>:
>>>>> Well. I made some progress but couldnt solve the claiming error yet..
>>>>> This is the current "dmesg" output when i press any key in my test
>>>>> scenario multiple times.
>>>>>
>>>>> ...
>>>>> usb 3-2: New USB device found, idVendor=0451, idProduct=3410
>>>>> usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
>>>>> usb 3-2: Product: USB2Serial +4GPIO
>>>>> usb 3-2: Manufacturer: UTICOM Diego
>>>>> usb 3-2: SerialNumber: TUSB3410 ):� v`�
>>>>> ti_usb_3410_5052_1 ttyUSB0: TI USB 3410 1 port adapter converter now
>>>>> disconnected from ttyUSB0
>>>>
>>>> I guess the problem comes from this event, when the device is
>>>> disconnected. I am not an USB
>>>> kernel driver expert, but I guess kernel frees the device resources
>>>> (including claiming) when
>>>> this happens. You can tell PyUSB to do everything again but calling
>>>> usb.util.dispose_resources.
>>>>
>>>
>>> That appears after dettaching the default driver.
>>>
>>> I now tried with both
>>> dispose_resources(self.dev)
>>> claim_interface(self.dev, self.interface)
>>> and none helped.
>>
>> Where did you put it? At the end of the loop, just before a new call
>> to raw_input?
>>
>
> dispose_resources at the initialization method.
> claim_interface after dispose_resources and before each read/write
> operation on endpoint1
>
> i also didnt saw anything in dmesg about "claiming interface" if it should.
> But dont bother about this.... raw_input is not of normal use and not
> the way that i will use it.
> Better bother about a normaliced error reporting, because the only
> difference between USBError for Timeout and USBError for Buffer
> overflow, is the string. I dont see how can i use except with it
> without catching both.
>
>>>
>>> One more tip..
>>> I noted this log since i am comunicating with endporint 1 IN and OUT
>>> to transfer data for the UART port.
>>>
>>>
>>>
>>>>> ti_usb_3410_5052 3-2:2.0: device disconnected
>>>>> usb 3-2: usbfs: process 12624 (python) did not claim interface 0 before
>>>>> use
>>>>> usb 3-2: usbfs: process 12624 (python) did not claim interface 0 before
>>>>> use
>>>>> usb 3-2: usbfs: process 12624 (python) did not claim interface 0 before
>>>>> use
>>>>> usb 3-2: usbfs: process 12624 (python) did not claim interface 0 before
>>>>> use
>>>>> usb 3-2: usbfs: process 12632 (python) did not claim interface 0 before
>>>>> use
>>>>>
>>>>>
>>>>>
>>>>> The error were produced by mistake of my in the firmware code, and now
>>>>> the requests are working perfectly.
>>>>>
>>>>> Because this device TUSB3410 is horrible badly documented, some parts
>>>>> of the "how this fucking register works!?!? " i had to figure out by
>>>>> trial and error.
>>>>> It seems like for every new coming OUT transmision i have to cancel or
>>>>> clear the status bits for any previus IN transfer and vicebersa. I
>>>>> write it here so it gets indexed in google.
>>>>>
>>>>>
>>>>>
>>>>> any way, the claiming is still an issue, but i am wondering if this
>>>>> have anything to do with the way that i set the test scenario with
>>>>>
>>>>> while raw_input(...):
>>>>>
>>>>>
>>>>> raw_input stops the code and waits for input, so .... my guess, is
>>>>> that if pyusb is not threaded or separate process, the it wouldnt be
>>>>> able to respond to libusb callbacks. Does this sounds reasonable?
>>>>
>>>> Yes, it does. I have been thinking about that, but only for a 1.1 version.
>>>>
>>>
>>> Looking forward then..
>>> Also, if you can facilitate an interface with usbmon to precisely
>>> generate a log file for the data transmitted, starting and stoping the
>>> logging with function calls, it will be great for debugging.
>>
>> I can consider your suggestion, but I am trying to cut away OS
>> specific features as most
>> as I can.
>>
>
> For Linux: usbmon or dtrace
> For solaris: dtrace and wrap usb_submit calls
> For FreeBSD: dtrace
> For windows: usbsnoop.sourceforge.net
>
> Please consider it, as i would like to see a portable usbsniffer in python.
> The major problem i see right now is if it should or not create an
> unified log format.
>
> Starting with usbmon, should be easy and allow tools like
> vusb-analyzer to be used.
>
> Cheers.
> Diego
>
>
>>>
>>>>>
>>>>> Thanks.
>>>>> Diego
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2010/7/9 Diego Jacobi <jacobidi...@gmail.com>:
>>>>>> If i am not mistaken... interface claiming is an OS thing, not a
>>>>>> firmware-possible problem.
>>>>>>
>>>>>> How can i know for sure that the interface is "claimed", and if
>>>>>> possible, force a "reclaim".
>>>>>>
>>>>>> Also, when i press the key for second time, there is a big pause going
>>>>>> (like 3 secs), which shouldnt, because the timeout is set to 100.
>>>>>> And also, it seems that it doesnt fails inmediately, it loses the
>>>>>> claim after a few requests.
>>>>>> check this logs. LOG lines are all ok.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> linux-7z8v:/home/diego/Desktop/TUSB3410/UTICOM/superterminal #
>>>>>> ./capafisica_usb.py
>>>>>> Presione una tecla
>>>>>> LOG(capafisica): OPEN usb device 0
>>>>>> LOG(capafisica): SET Config GPIO [0]
>>>>>> LOG(capafisica): SET GPIO(0x 3, 0xffff) 0
>>>>>> LOG(capafisica): PINGing device 15
>>>>>> LOG(capafisica): SET GPIO(0xff, 0x c) 0
>>>>>> LOG(capafisica): GET GPIO 3311
>>>>>> array('B', [72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33])
>>>>>> LOG(capafisica): SET GPIO(0xff, 0x c) 0
>>>>>> LOG(capafisica): GET GPIO 3311
>>>>>> array('B', [72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33])
>>>>>> LOG(capafisica): SET GPIO(0xff, 0x c) 0
>>>>>> LOG(capafisica): GET GPIO 3215
>>>>>> array('B', [72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33])
>>>>>> LOG(capafisica): SET GPIO(0xff, 0x c) 0
>>>>>> LOG(capafisica): GET GPIO 3215
>>>>>> array('B', [72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33])
>>>>>> Presione una tecla
>>>>>> <-------------------------------------------------------------------------------------------
>>>>>> HERE THERE IS A BIG DEADTIME
>>>>>> LOG(capafisica): OPEN usb device 0
>>>>>> LOG(capafisica): SET Config GPIO [0]
>>>>>> LOG(capafisica): SET GPIO(0x 3, 0xffff) 0
>>>>>> LOG(capafisica): PINGing device 15
>>>>>> LOG(capafisica): SET GPIO(0xff, 0x c) 0
>>>>>> LOG(capafisica): GET GPIO 3247
>>>>>> _check ERROR: -1 Input/output error
>>>>>> ----> ERROR(capafisica): EXCEPTION trying to send data with
>>>>>> (timeout,error) <class 'usb.core.USBError'>
>>>>>> ====> DEBUG(capafisica): ----------------- USBError('Input/output
>>>>>> error',)
>>>>>> File "./capafisica_usb.py", line 203, in try_send
>>>>>> ....
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2010/7/9 Wander Lairson <wander.lair...@gmail.com>:
>>>>>>> 2010/7/9 Diego Jacobi <jacobidi...@gmail.com>:
>>>>>>>> Hi.
>>>>>>>>
>>>>>>>> As you may know, i am working in a device using an TUSB3410 with my
>>>>>>>> own firmware.
>>>>>>>>
>>>>>>>> Most is working.
>>>>>>>> I plug the device it logs in linux correctly and i am able to detach
>>>>>>>> the driver and make usb requests with pyusb.
>>>>>>>>
>>>>>>>> The problem comes when it has deadtime between calls then i get the
>>>>>>>> next message in dmesg:
>>>>>>>>
>>>>>>>> usb 3-2: usbfs: process 7564 (python) did not claim interface 0 before
>>>>>>>> use
>>>>>>>>
>>>>>>>> I can not find any method for claiming interface in pyusb. Is there
>>>>>>>> one?
>>>>>>>
>>>>>>> PyUSB 1.0 manages interface claiming automatically, but it can only do
>>>>>>> so if all stuff is done through PyUSB. It interface is released
>>>>>>> outside
>>>>>>> PyUSB, it cannot figure it out. Also, this might be a bug in PyUSB.
>>>>>>>
>>>>>>>>
>>>>>>>> Some more details:
>>>>>>>>
>>>>>>>> I made a class to handle the requests (capafisica) and a test scenario:
>>>>>>>>
>>>>>>>> if __name__ == '__main__':
>>>>>>>> fisica = capafisica()
>>>>>>>> fisica.logging = fisica.LOGGING_DEBUG
>>>>>>>> while raw_input("Presione una tecla")>0:
>>>>>>>> fisica.try_start()
>>>>>>>> fisica.test()
>>>>>>>> fisica.set_gpio(0xFF,mask=0x0C)
>>>>>>>> fisica.get_gpio()
>>>>>>>> fisica.try_send("Hello World!")
>>>>>>>> print fisica.try_recv()
>>>>>>>>
>>>>>>>>
>>>>>>>> When i press a key it launches the set of functions and all works
>>>>>>>> correctly. IF i press a key again, then most of them fails, i may say,
>>>>>>>> randomly. AND this error message in dmesg appears.
>>>>>>>>
>>>>>>>> However if i edit the test scenario to:
>>>>>>>>
>>>>>>>> if __name__ == '__main__':
>>>>>>>> fisica = capafisica()
>>>>>>>> fisica.logging = fisica.LOGGING_DEBUG
>>>>>>>> while raw_input("Presione una tecla")>0:
>>>>>>>> fisica.try_start()
>>>>>>>> fisica.test()
>>>>>>>> fisica.set_gpio(0xFF,mask=0x0C)
>>>>>>>> fisica.get_gpio()
>>>>>>>> fisica.try_send("Hello World!")
>>>>>>>> print fisica.try_recv()
>>>>>>>> fisica.try_start()
>>>>>>>> fisica.test()
>>>>>>>> fisica.set_gpio(0xFF,mask=0x0C)
>>>>>>>> fisica.get_gpio()
>>>>>>>> fisica.try_send("Hello World!")
>>>>>>>> print fisica.try_recv()
>>>>>>>> fisica.try_start()
>>>>>>>> fisica.test()
>>>>>>>> fisica.set_gpio(0xFF,mask=0x0C)
>>>>>>>> fisica.get_gpio()
>>>>>>>> fisica.try_send("Hello World!")
>>>>>>>> print fisica.try_recv()
>>>>>>>> fisica.try_start()
>>>>>>>> fisica.test()
>>>>>>>> fisica.set_gpio(0xFF,mask=0x0C)
>>>>>>>> fisica.get_gpio()
>>>>>>>> fisica.try_send("Hello World!")
>>>>>>>> print fisica.try_recv()
>>>>>>>>
>>>>>>>>
>>>>>>>> Then all the calls works.
>>>>>>>> In that way i discard that can be a problem in my firmware. Well, i do
>>>>>>>> not discard it completely, but i need to know how to "claim the
>>>>>>>> interface"
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Diego
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> This SF.net email is sponsored by Sprint
>>>>>>>> What will you do first with EVO, the first 4G phone?
>>>>>>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>>>>>>> _______________________________________________
>>>>>>>> pyusb-users mailing list
>>>>>>>> pyusb-users@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best Regards,
>>>>>>> Wander Lairson Costa
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> This SF.net email is sponsored by Sprint
>>>>>>> What will you do first with EVO, the first 4G phone?
>>>>>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>>>>>> _______________________________________________
>>>>>>> pyusb-users mailing list
>>>>>>> pyusb-users@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> This SF.net email is sponsored by Sprint
>>>>> What will you do first with EVO, the first 4G phone?
>>>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>>>> _______________________________________________
>>>>> pyusb-users mailing list
>>>>> pyusb-users@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards,
>>>> Wander Lairson Costa
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net email is sponsored by Sprint
>>>> What will you do first with EVO, the first 4G phone?
>>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>>> _______________________________________________
>>>> pyusb-users mailing list
>>>> pyusb-users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Sprint
>>> What will you do first with EVO, the first 4G phone?
>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>> _______________________________________________
>>> pyusb-users mailing list
>>> pyusb-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>>>
>>
>>
>>
>> --
>> Best Regards,
>> Wander Lairson Costa
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> pyusb-users mailing list
>> pyusb-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> pyusb-users mailing list
> pyusb-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>
--
Best Regards,
Wander Lairson Costa
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
pyusb-users mailing list
pyusb-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pyusb-users
