On Thu, Nov 17, 2016 at 1:26 AM, Geoff Roddick wrote:
> Hi,
>
> I'm have been unable to access the 2nd, 3rd or 4th port of the FTDI FT4232H.
> I can successfully bit bang or use SPI on Port A.
>
> I thought changing the interface would work, but both 0 and 1 access Port A
> and 2 gives me
> GpioEx
Foreword: Please do not reply to digest messages (or without editing
the subject), as tracking threads is quite difficult :-) Thanks.
> I understand. I think what I was proposing was less drastic: I think
> the UsbSerial class (and indeed the whole serialext package) is more
> general than just fo
On Sun, Apr 19, 2015 at 2:53 AM, Chapman Flack wrote:
>> Reactions? Does my dream make sense to other pyusb-users readers?
Hi,
A quick note about the licensing scheme of pyftdi (and friends).
Some parts are LGPL-licensed because I've initially developed cftdi on
top of libftdi - a Python-to-C wr
> It hasn't. This is a fresh compile under 10.6.8. I am trying -- hard -- to
> avoid using homebrew and similar.
I personally never broke my systems with Homebrew (but I did several
time with MacPorts and Fink), and I now use it intensively, but I
guess that YMMV.
> Adding libusb path to DYLD_LIB
Adding libusb path to DYLD_LIBRARY_PATH should be enough.
I'm using this syntax daily on OS X without any issue.
If libusb(x) has been installed with Homebrew:
export DYLD_LIBRARY_PATH="/usr/local/opt/libusb/lib"
$> ls -l /usr/local/opt/libusb/lib/
total 464
-r--r--r-- 1 eblot admin 93280 2
> The package python-usb of wheezy must be 0.4...
> I recommend download the 1.0 version of PyUSB:
>
> http://sourceforge.net/projects/pyusb/files/PyUSB%201.0/1.0.0-alpha-3/
You can install 1.0.0* from pip:
(sudo) pip install pyusb
Cheers,
Manu
--
> I am trying to get pyusb working on OSX 10.8 with Python 2.7 (my goal is
> to be able to communicate with a novation nocturn using python, see
> https://github.com/dewert/nocturn-linux-midi which relies on pyusb.)
>
> I installed libusb 1.0 through macports
Good news is that libusb / pyusb / OSX
> Actually most of the Linux distros are now using libusbx as the
> libusb-1.0 API provider, Fedora, Debian/Ubuntu, Arch, etc.
>
> libusbx.org have some more information if you feel it is
> confusing.
> http://libusbx.org/
Hi Xiaofan,
The switch from libusb to libusbx is not confusing -on its own
> Debian/ubuntu packages..
> when you make: apt-get install python-usb
>
> the latest (in the dev branch) is 0.4.3-1
> The 1.0 (alfa 1, 2, 3.. etc..) must be packaged !
I do prefer using pip to manage Python package on Debian / Ubuntu /
whatever / .. OS X.
The main reason is actually to use severa
> I not like that change. If someone want to use both versions, rename
> it and use..
I agree: who many installations would be broken once pyusb is updated?
All Python modules that depends on "pyusb" would have to be updated,
this is not a trivial task.
My two cents,
Manu.
--
> AFAIK, status command is standard for USBPrint Class, please check the
> doc I pointed to you...
Yes, it's implemented this way in the code I sent in my previous email.
Cheers,
Manu
--
LogMeIn Rescue: Anywhere, Anytime
Hi Marco,
I wrote a quick driver based on pyusb a couple of months ago, for USB printers.
You may want to have a look at the source code, I've just gisted a
copy of it here:
https://gist.github.com/4336647
'BitField' class is implemented here:
https://github.com/eblot/pyftdi/blob/master/pyftdi/p
> I don't have a usb sniffer. Can you recommend one for windows? It should be
> easy to use.
The USB tool from HHD is great (but not free):
http://www.hhdsoftware.com
--
Everyone hates slow websites. So do we.
Make your
> Do you mean the alpha number?
Yes. I guess it can be anything, maybe even rc1?
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how
I would also suggest to change the version in setup.py as the internal
API has changed (usb backends have be renamed for example since alpha
2).
Cheers,
Manu
--
Live Security Virtual Conference
Exclusive live event will c
> Please, pull it again, there was a typo in the code. I look for both
> 'mac' and 'darwin', I don't know not exactly why, I took this code
> from an old patch for PyUSB 0.
Hi Wander,
libusb0 backend now seems to work on my Mac (OS X 10.8).
I tested it against libusb-compat 0.1.4 + libusb 1.0.9
> if sys.platform.startswith('freebsd') or sys.platform.find('mac') != -1 or
I think you want to look for "darwin", not "mac":
>>> import sys
>>> sys.platform
'darwin'
--
Live Security Virtual Conference
Exclusive li
>> Just was exactly the problem. I just pushed the fix for Mac, could you
>> test it, please?
Not sure this was expected:
$> PYTHONPATH=. python tests/test_backend.py
--
Ran 0 tests in 0.000s
Anyway, a backslash is missing:
Tr
> Just was exactly the problem. I just pushed the fix for Mac, could you
> test it, please?
Sure: what UT do you want me to run?
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's sec
>> I believe the Max OSX issue is the same, and also other BSDs should
>> suffer from the same problem. Could someone with access to Mac OSX
>> check what's the value of PATH_MAX macro? We need to know that value
>> for NetBSD and OpenBSD (does libusb 0 run under NetBSD and OpenBSD?).
I got burnt
On Sun, Aug 12, 2012 at 4:55 PM, Wander Lairson Costa
wrote:
> I believe the Max OSX issue is the same, and also other BSDs should
> suffer from the same problem. Could someone with access to Mac OSX
> check what's the value of PATH_MAX macro? We need to know that value
> for NetBSD and OpenBSD (d
Hi Wander,
I can confirm that on Mac OS X 64 bits (10.8 GM), using bulk transfer:
* libusbx (1.0.12) works fine
* libusb (1.0.8) works fine
* libusb-0.x (0.1.12) cannot enumerate devices
I have not tested libusb-compat
Cheers,
Manu
-
> You do not need to install the legacy libusb-0.1 under Mac OS X.
> You just need to use the libusb-compat. libusb-0.1 is no longer
> maintained under Linux and Mac OS X but libusb-compat is
> still maintained.
It depends what wea actually want to test… Wander, wha'ts your opinion?
Cheers,
Manu
> I think no need to drop since libusb-compat is still maintained.
Sure, but what's the point of maintaining *two* backends, as the
second one (-compat) requires the first one to execute?
Maitaining libusb-compat is required for native application that rely
on the old API, but as long as PyUSB abs
Un*x-like hosts (Linux, OS X, FreeBSD)?
Many native projects still use libusb 0.x API, but only throught the
libusb-compat wrapper, i.e. the actual libusb library is a 1.x series.
Cheers,
Manu
On Tue, Jul 10, 2012 at 11:29 AM, Emmanuel Blot wrote:
>> Thanks, Emmanuel. Would you mind ch
> Thanks, Emmanuel. Would you mind checking ticket #10 [1] ?
I'll attempt to install libusb-0.x w/o messing up my whole system, and
see if I can use it.
I'll keep you posted.
Cheers,
Manu
--
Live Security Virtual Confere
On Mon, Jul 9, 2012 at 3:31 PM, Wander Lairson Costa
wrote:
>> 4) Is there someone with a *BSD machine to make at least basic tests?
>> And about Mac OSX?
We are using PyUSB on OS X (10.7, 10.8) [team of 5 people] and Linux
on Ubuntu & Buildroot [team of 15 people], with libusb10 backend and
bulk
On 5 Jul 2012, at 01:18, Wander Lairson Costa wrote:
> IMO, there is no point in releasing a new version which changes
> nothing. Also, I see no good point releasing 1.0 as stable with
> possibility of radical changes in the API yet.
Conversely, it could be a real issue for many projects if th
Hi Xiaofan,
> libusb-win32 still uses libusb-0.1 API (with extensions on its own
> async APIC and isoc support for Windows).
Ok, thanks for the update
> How do you install the driver? Take note you need to install
> a suitable driver for your device to use libusb-win32.
I think this is the part
> I've documented what worked for me (win7 32 bit)
> http://code.google.com/p/dava33display/wiki/PythonVersion
I have not thought about rebooting after installation, I should give it a try.
> http://sourceforge.net/projects/libusb/
Ok thanks,
Manu
---
Hi Wander,
> I think latest release of libusb-win32.
What's the backend: libusb 1.x or libusb 0.1? I got controversial
information about it.
>> Target is Windows 7 x64 Pro, with pyusb-1.0.0a2 and Python 2.7
> Well, I've tested it only on Windows 32 bits…
I successfully installed and run libusb-
Hi All,
I never succeeded to run pyusb on Windows, but I'd like to give it another try.
Any recommendations about the libusb release to install ?
Target is Windows 7 x64 Pro, with pyusb-1.0.0a2 and Python 2.7
I've downloaded and installed libusb-win32 (1.2.6.0), but it leads to
this error messa
Hello Wander,
> Yes, you are right, I haven't realized that. It seems that to keep
> things easy we can't run away of this kind of trade off..
I don't think using Interface instance instead of interface number is a problem.
However, I think it should be stated somewhere in the documentation
that
> pyftdi here?
> https://github.com/eblot/pyftdi
true.
> libftdi has its own Python binding as well. What is the main difference
> of your pyftdi?
PyFtdi does not need libftdi at all: it's a pure Python implementation.
However, I also maintain a closed-source version of PyFTDI (cftdi.py)
that exp
Hello,
We have been facing performance issues with PyUSB.
As our code can run with both pyftdi/libftdi/libusb (Py/C/C) or
pyftdi/pyusb/libusb (Py/Py/C), we have profiled the code and observed that the
stack based on the native libftdi librarie performs far better than the one
based on the pyus
> You must patch the code, as far as I know there is no other way. What
> can be done is to
> optimize the methodloggers.
Here is a simple proposal:
https://gist.github.com/605c3611622890e0d78c
Simply disable do_trace evaluation when no debug trace level is set.
Cheers,
Manu
---
Hello,
Enumerating USB devices on the host buses may be quite time consuming.
I need to enumerate these devices a couple of times at startup, and pyusb does
not cache the results.
The net performance penalty here is 0.7 second per "core:find" call, which slow
down my application start up time.
On 17 mars 2011, at 10:33, Chris wrote:
> Still no dice. It's a head scratcher. I must be missing something.
I guess you would get a more explicit message, but what if Python is running in
64-bit mode and your libs are only built as 32-bit binaries?
You may want to double check this point.
> It seems like libusb isn't installed correctly, but I used 'sudo apt-get
> install libusb' and after installing pyusb openusb.py, libusb10.py and
> libusb01.py are in /sw/lib/python2.5/site-packages/usb/backend. Am I
> missing something?
Try defining the path for the dynamic loader:
export DYLD
> It is a feature (obtain device bus number) that already has been
> requested, and is scheduled to alpha 2 release.
BTW, would it not be easier to release pyusb-1.0.0a1 as pyusb 1.0.0 as
it seems quite stable now, and add new features such this (useful ;-))
one in a new 1.1.x release?
Cheers,
Ma
> However, it does not seems that pyusb exposes this information.
Here is a sample patch to enable these entry points with libusb-1.0,
against pyusb-1.0.0a1
This patch cannot be integrated as is, as I've not checked how to
implement their equivalent for neither libusb-0.1 nor openusb-x
Using a c
> Is there any way to compare/test whether two usb.core.Device instances
> do actually refer to the same physical device?
Looking at the libusb1.0 interface, it seems that the following entry points
/** \ingroup dev
* Get the number of the bus that a device is connected to.
* \param dev a devi
Hi,
I bumped into an issue when initializing a device.
The device (FTDI chip) offers up to four similar UART/serial ports,
each port is tied to a USB interface.
I use the following piece of code:
dev = usb.core.find(idVendor=vendor, idProduct=product)
if not dev:
raise IOError('D
Hi,
I'd like to manage several USB slaves that may have the exact same hardware:
vendor id, product id and even serial identifier may be the same.
It does not seem that pyusb 1.0 offers by bus-related information, so
I don't know how to differentiate those devices.
Is there any way to compare/te
On Mon, Jan 3, 2011 at 11:17 PM, mike s wrote:
> Mac OSX 10.6.5
> ValueError: No backend available
Be sure that the libusb dynamic library can be found by the loader.
Try
export DYLD_LIBRARY_PATH=/path/to/the/lib_directory
otherwise
Cheers,
Manu
--
On Mon, Jan 17, 2011 at 4:31 PM, Sridev Nair wrote:
> Some issue related to port opening & response capture which I am unable to
> figure out.
I think at this point, it would be helpful to spy on the USB bus to
see what's going on with the driver that works, and compare it with
the command you se
> This is a different command. As per the vendor, this is the first command to
> run on port open.
Are you sure it is a control request, not a simple bulk transfer ?
>>> msg_str = binascii.unhexlify("020200013803")
> Tried it, no difference.
You need to know if you want to send hexadecimal data
>> results = readerHandler.controlMsg(64, msg_str, data, timeout=1000)
> The correct prototype for the method controlMsg is
> controlMsg(requestType, request, buffer, value = 0, index = 0, timeout
> = 100),
> thus you should at least supply the requestType and request
> parameters, which is not hap
> With the pyserial wrapper for pyftdi, it would be as simple as the
> following code snippet:
FWIW: I just delivered the serialext module that allows to use the
FTDI as a regular pyserial communication port.
The pyftdi/tests directory contains a code sample that can be used as
a basic serial term
> Plain Python 2.6 Windows works fine.
I've installed the driver with Zadig for the USB device, which is connected.
Before copying the DLL, I got the "No backend available" error, so I
guess that now the DLL is found.
I've copied
\libusb_2010.12.10\MS64\dll\libusb-1.0.dll into System32, and
> So, maybe it is just a matter of adding /usr/bin for library search
> path. Going to check that when have some time...
AFAICT from my yesterday unsuccessful attempts, ctypes (cygwin /
Python 2.6.5) automatically find the cygusb-1.0.*dll libraries from
/usr/bin, the dedicated "cygwin" case in pyu
> Cygwin is still unsupported. I've given just a shallow look on Cygwin,
> but it feels like it just has the static versions of libusb 1.0 and
> libusb-win32.
The dynamic libraries (cygusb*.dll) are located in /usr/bin/, not in /usr/lib/
http://cygwin.com/packages/libusb1.0/libusb1.0-1.0.7+gitbd62
> libusb 1.0 uses WinUSB, which I am not sure is
> available in Windows XP (I guess so, you might find some info in the
> libusb.org website)
It seems it is supported since WinXP SP2:
http://msdn.microsoft.com/en-us/library/ff540196.aspx
but some specific files need to be installed.
I missed thi
> I am using an automatic power supply which has FTDI interface to talk to it.
> I need to read the voltage and current details from it and also write data
> to it for controlling the power supply.
So if my understanding is correct, you are using the FTDI device as a
simple USB-to-serial converter
> because it is not directly related to USB, and moreover it is
> platform-specific (Windows only, I guess)
Update: it seems that 1.0.0 version of D2XX for Linux and Mac OS X
have been released in December '10.
--
Learn h
Hello,
Did anyone succeed running pyusb (or even libusb...) under Windows ?
I've tried on Windows XP 32-bit the following combinations, without any success:
1. Python 2.6.5/Cygwin 1.7, libusb-win32
2. Python 2.6.5/Cygwin 1.7, libusb-1.0.5+git
3. Python 2.6.5/Cygwin 1.7, libusb-1.0.7+git
4. P
> Well, renaming that would be the perfect solution, in my opinion, as
> it is not a general puporse USB module, but I was referring to "our"
> pyusb, maybe calling it python-usb, as Ubuntu does...
Ok, I understand.
It would be exactly like pyserial, which is named python-serial in
Debian/Ubuntu a
>> Note: it is really weird idea to name a d2xx Python module as "pyusb" ;-(
>>
> Just wondering if it is time to rename this project to avoid this kind
> of mistake...
It would be nice if that project got renamed as "pyd2xx" or the like,
because it is not directly related to USB, and moreover it
> Could you please provide an example for the library you have created so that
> it helps in understanding the usage of the functions.
The projet is being built at the moment, so I've had no time yet to
write the documentation.
Moreover, for now pyftdi only contains the code to send control and
d
Hello Karthikeyan,
[OT] Please use a new thread when posting a new question, do not reply
to an existing, unrelated thread.
d2xx is a library from FTDI Ltd, and it looks like you are referring
to PyUSB from http://bleyer.org/pyusb/, which is a different project.
In other words, you've posted to
>> File
>> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/usb/core.py",
>> line 829, in find
>> raise ValueError('No backend available')
>> ValueError: No backend available
On Mac OS X, you can simply add the path to the dynamic library this way:
DYLD_LIBRARY
> It seems so. At least it works with the code snippet, I'll try on the
> real code later tonight
Works nice.
Thanks again,
Cheers,
Manu
--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to co
> Any help/insight?
Just a thought:
Are you sure the USB device does not expect some configuration (using
control request, such as parity, baudrate, ...) prior to sending the
actual data to the serial output ?
That might explain why it works when the demo code opens the port (it
may explicitly co
> I guess I found the problem.
It seems so. At least it works with the code snippet, I'll try on the
real code later tonight
> And the *real* correct way to do it (independent of version) is:
> DEV_OUT_REQTYPE = usb.util.build_request_type(
> usb.util.CTRL_OUT,
>
> Maybe you could post the whole code in pastebin, and in the email body
> the code snippet..
Here it is:
http://pastebin.com/0S1Ce9zt
I've removed everything from the original code to demonstrate the
"issue" (which may be a wrong usage of pyusb at first ;-)), so do not
expect the code to do any
> Could you please post the test code?
Sure, I'll do it
Either I'll wrote a code snippet to reproduce it, or I will post the
whole Python module.
Thanks,
Manu
--
Learn how Oracle Real Application Clusters (RAC) One Node
Hi,
I've just updated to pyusb-1.0.0a1 and it seems that there is some
kind of regression on Mac OS X host (64-bit kernel, libusb 1.0.8
backend):
pyusb100a1 is a virtualenv with pyusb 1.0.0a1 installed:
File "pyusb100a1/lib/python2.7/site-packages/usb/core.py", line 678,
in ctrl_transfer
s
> Of course I will not impose any restrictions if you want to submit it
> to pypi... :)
Ok, if I have some spare time, I'll do it.
I'd like to submit a client of pyusb (pyftdi).
Let me known which email address to use for your author email.
Cheers,
Manu
-
Hello Wander,
> I am not used to pypi, but I guess pypi team is responsible for that, right?
AFAICT, a developer may submit a new package to PyPi, see:
http://wiki.python.org/moin/CheeseShopTutorial#SubmittingPackagestothePackageIndex
It would be really great.
Cheers,
Manu
Hello,
pyusb-1.0 alpha seems quite stable.
What about updating the pyusb entry @ pypi so that package management
can be used with this new version of PyUSB?
http://pypi.python.org/pypi/pyusb/0.4.2
For now, writing package that are based on pyusb 1.0 is quite
difficult, as dependency management c
70 matches
Mail list logo
