roboknight / libmpsse Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/libmpsse
Automatically exported from code.google.com/p/libmpsse
What steps will reproduce the problem?
1. Download package, untar it, and run ./configure on CentOS 5.9
What is the expected output?
configure can find python include files
What do you see instead?
...
checking /usr/include/pythonoption usability... no
...
What version of the product are you using? On what operating system?
CentOS 5.9
Please provide any additional information below.
My version of python (python 2.4) doesn't support the --version option. When I
replaced --version with -V on line 4724 of configure, it worked.
Original issue reported on code.google.com by [email protected]
on 15 Mar 2013 at 8:21
What steps will reproduce the problem?
1. run the attached file with an FT232H attached
2. notice how everything works
3. comment out the WRITE_BEFORE_READ macro to disable the write command
What is the expected output? What do you see instead?
I would expect the read command to work without a preceding write command.
Instead, the kernel detaches the device with the following message in the dmesg
output, while the cable is still plugged in and connected to the USB port:
[37074.838315] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now
disconnected from ttyUSB0
[37074.838335] ftdi_sio 2-1.5:1.0: device disconnected
The read command only works if I write at least 1 byte before.
What version of the product are you using? On what operating system?
libmpsse-1.2, ubuntu 11.04 amd64 compiled as 32bit
Please provide any additional information below.
I'm using the readymade MPSSE cable from FTDI, only connected to a scope.
I am also seeing that replacing the Read/Wrie combination with a call to
"Transfer" causes the kernel to detach the device in a similar fashion.
When plugging in the cable, the usb connection sequence logs as follows:
[37069.942923] usb 2-1.5: new high speed USB device number 16 using ehci_hcd
[37070.040969] ftdi_sio 2-1.5:1.0: FTDI USB Serial Device converter detected
[37070.041014] usb 2-1.5: Detected FT232H
[37070.041017] usb 2-1.5: Number of endpoints 2
[37070.041020] usb 2-1.5: Endpoint 1 MaxPacketSize 512
[37070.041024] usb 2-1.5: Endpoint 2 MaxPacketSize 512
[37070.041027] usb 2-1.5: Setting MaxPacketSize 512
[37070.041340] usb 2-1.5: FTDI USB Serial Device converter now attached to
ttyUSB0
Original issue reported on code.google.com by [email protected]
on 18 Jul 2012 at 6:42
Attachments:
What steps will reproduce the problem?
1. incorrect compiled libmpsse.(a/so) if make is run multiple times,
2.
3.
What is the expected output? What do you see instead?
same result each time one runs make with C library containing C version and
swig library containing swig version.
Instead the C library contains the swig version of functions if make is run
twice.
What version of the product are you using? On what operating system?
SVN 202, Linux
Please provide any additional information below.
Patch attached.
Original issue reported on code.google.com by [email protected]
on 28 Jan 2014 at 2:59
Attachments:
What steps will reproduce the problem?
1. Download and build libmpsse R121 revision (using libusb-0.1.12 libftdi-0.20)
2. Build 'gpio.c' example
3. Run gpio example
What is the expected output? What do you see instead?
Example runs smoothly, except that it crashes with a segfault when
MPSSE.GPIO.Close is called.
What version of the product are you using? On what operating system?
R121 on Linux Ubuntu
Original issue reported on code.google.com by [email protected]
on 26 Oct 2012 at 12:06
What steps will reproduce the problem?
1. Establish an i2c context
2. PinHigh(ctx, GPIOL2)
3.
What is the expected output? What do you see instead?
Expected output is that GPIOL2 is in high state but no other changes to pin
state.
But actual effect is that a I2C start condition is unexpectedly being sent,
causing problems for following I2C transaction.
What version of the product are you using? On what operating system?
SVN Revision 202. Linux.
Please provide any additional information below.
Patch attached.
Original issue reported on code.google.com by [email protected]
on 28 Jan 2014 at 2:53
Attachments:
What steps will reproduce the problem?
1. There really aren't any steps here, it appears there isn't any way to set
pin direction for bitbang mode or to set all pins at the same time.
Please provide any additional information below.
I was looking for a way to "bulk" set the pins of a particular interface in
bitbang mode. It appears that I can read and write them using PinHigh/PinLow
individually. This is certainly useful, but I wanted to be able to "set them
all at once" for an application I am doing. In this case, I have a sort of
"JTAG finder" that can scan pins and "hunt" for JTAG. In order for that to
work though, I have to be able to change the pin direction as well as be able
to set pins "all at once". So I created a SetDirection and a WritePins
function.
I don't know if you will find them generally useful or not, but I thought they
could be. Even without the WritePins functionality, I figured the SetDirection
might be needed in BitBang mode.
It is a patch against the latest release, *NOT* the latest SVN. Hope that
doesn't create any issues. At any rate, it does seem to work and my JTAG
finder appears to do the job.
libmpsse really is one of the neatest libraries out there. I guess that is
because it is connected with some of the coolest/cheapest hardware I've seen in
a while. It can REALLY get your PC/laptop connected to a lot of hobby stuff.
Original issue reported on code.google.com by [email protected]
on 28 Dec 2012 at 6:12
Attachments:
The FT232H supports open-drain outputs to become fully I2C compatible. This
prevents bus conflicts when a slave device tries to acknowledge.
Original issue reported on code.google.com by [email protected]
on 26 Apr 2013 at 4:03
Attachments:
What steps will reproduce the problem?
case 1. run b.c from issue #10, measure the clock rate
case 2. change the clock rate to 15000000 (15MHz), rebuild and run
case 3. change the clock rate to 15000001 (15.000001MHz), rebuild and run
What is the expected output? What do you see instead?
case 1. expected = 25MHz, seen = 30MHz (bad)
case 2. expected = 15MHz, seen = 15MHz (good)
case 3. expected = 15MHz, seen = 30MHz (bad)
What version of the product are you using? On what operating system?
verified with libmpsse-1.1 and -1.2
Please provide any additional information below.
ubuntu 11.04 running on 3.0.0-23-generic/x64
The hardware in use is the MPSSE-3.3V cable from FTDI based on the FTDI232H
Original issue reported on code.google.com by [email protected]
on 25 Jul 2012 at 4:07
THIRY_MHZ must be THIRTY_MHZ
TEN_MHZ != 1000000 it must be TEN_MHZ = 10000000
Original issue reported on code.google.com by [email protected]
on 16 Jan 2012 at 3:29
Attachments:
What steps will reproduce the problem?
1. Installed libmpsse-1.2-1 in ubuntu 12.04 LTS
2. Using with the hardware C232HM USB 2.0 Hi-Speed to MPSSE cable.
3. Then ran examples
What is the expected output?
Should work
What do you see instead?
Failed to open MPSSE: device not found
What version of the product are you using? On what operating system?
libmpsse-1.2-1 in ubuntu 12.04 LTS
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 7 Mar 2013 at 6:27
Hi,
I see in your code a lot of malloc/memcopy/free calls. All this stuff heavily
impact the performances (latency) of the code (which are very important on my
use case) so I wrote a couple of additional files (fast_spi_mpsse.h/c) in order
to speed-up the SPI (and only SPI) transfer by removing all but one mandatory
memcopy.
The new functions are basically the same as the ones found in your code except
that the rx and tx buffer (and their size) need to be provided by the user.
I also did a really minor change on the MPSSE function (interface is now a
parameter).
I attach the patch file including all the above changes, feel free to to use
that code by your convenience.
Cheers,
Paolo.
Original issue reported on code.google.com by [email protected]
on 20 Mar 2013 at 4:55
Attachments:
Add this to prevent type issues in python when using types other than basic int.
Original issue reported on code.google.com by [email protected]
on 29 Nov 2013 at 4:25
Attachments:
The attached patch fixes misc. issues in the Makefile that make easier the
packaging of libmpsse.
This patch is for the libmpsse-1.2 release, and has been generate from the
tarball.
To apply this patch:
$ tar xaf libmpsse-1.2.tar.gz
$ cd libmpsse-1.2
$ patch -p0 <libmpsse-1.2-fix-Makefile.patch
Yours,
Original issue reported on code.google.com by [email protected]
on 11 Sep 2012 at 6:25
Attachments:
What steps will reproduce the problem?
1. Try to call FastTransfer
2.
3.
What is the expected output? What do you see instead?
That the transfer gets carried out. But it always errors.
What version of the product are you using? On what operating system?
SVN #202. Linux.
Please provide any additional information below.
Patch attached.
Original issue reported on code.google.com by [email protected]
on 30 Jan 2014 at 6:59
Attachments:
What steps will reproduce the problem?
Set MPSSE to Ack following each read byte.
Perform an I2C Read followed by a Stop. The number of bytes read doesn't
matter.
What is the expected output? What do you see instead?
Using a logic analyzer, I can see that where the stop is issued, the SCL line
goes high but the SDA line always stays low. The next I2C operation fails
because a valid start condition can't be generated.
Calling SendNacks and issuing a dummy read is incorrect if you are trying to
read from a device that has a FIFO buffer or auto-incrementing support.
What version of the product are you using? On what operating system?
LibMPSSE v1.3 along with ftdi v1.0 on OSX 10.8.5
Please provide any additional information below.
I've tried forcing the SDA line high with a variety of set_bits or PinHigh
calls without success. I've tried using the FlushAfterRead call as well. I'm
trying to talk to an Invensense MPU9150 digital motion processor.
Original issue reported on code.google.com by [email protected]
on 25 Sep 2013 at 3:47
The comment says that pins are set to input/low, however, they are actually set
to output (trish = 0xFF). This might be dangerous for some hardware.
Section 3.6.2 from:
http://www.ftdichip.com/Support/Documents/AppNotes/AN_108_Command_Processor_for_
MPSSE_and_MCU_Host_Bus_Emulation_Modes.pdf
Original issue reported on code.google.com by [email protected]
on 17 Jan 2013 at 1:57
I am patronized libmpsse!!
The current version(1.3) available only one device.
I've created a patch that supports multiple deive(up to four).
As Chip Select, CS, GPIO0, GPIO1, GPIO2 can be use.
usage:
c:
mpsse_= OpenIndexWithCS(vid, pid, mode, freq, endianess, interface, description, serial, index, {CS|GPIO0|GPIO1|GPIO2});
python
mpsse = MPSSE()
mpsse = mpsse.Open(vid, pid, mode, cs={CS|GPIO0|GPIO1|GPIO2})
My environment
BeagleBone Black / Debian(wheezy)
Raspberry Pi / Raspbian(2013-09-25-wheezy)
If it is good, Please relish.
Thank you.
Original issue reported on code.google.com by [email protected]
on 9 Nov 2013 at 8:44
Attachments:
What steps will reproduce the problem?
1. Run the attached code changing the slave address to whatever slave address
your I2C device uses and to whatever register you can read and write to
2. I included some code that uses the ftdi command that would clock in the
data, which does work. Just comment that out and uncomment the part right after
//Read 1 of the registers.
What is the expected output? What do you see instead?
The expected outcome is whatever you wrote to the address. I just get a seg
fault. When trying to print the pointer to the data, I just get the size that I
inputted to the Read command
What version of the product are you using? On what operating system?
Using libmpsse-1.3 on Fedora 19
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 27 Sep 2013 at 8:26
Attachments:
What steps will reproduce the problem?
1. Open device in SPI or I2C mode
2. call SetDirection method
3. Exception is thrown
What is the expected output? What do you see instead?
I was unable to set specific pin to input mode when in MPSSE mode. I recommend
attached patch
Additional information
mpsse.i.patch described under issues had to be applied in advance
What version of the product are you using? On what operating system?
libmpsse-1.3 on linux ubuntu
Original issue reported on code.google.com by [email protected]
on 18 Jun 2014 at 1:29
Attachments:
What steps will reproduce the problem?
1. With lattop, install MinGW with msys shell in C:\MinGW
2. copy "libftdi1-1.0_devkit_mingw32_17Feb2013" lib\ and bin\ and include\
folder into C:\MinGW
3. In msys shell run mingw-get install mingw32-automake mingw32-autotools
mingw32-autoconf
4. copy "libmpsse-1.3" to c:\libmpsse-1.3
5. In msys shell "cd c:\libmpsse-1.3\src"
6. In msys shell "autoconf && ./configure --disable-python && make"
7. In msys shell "make install"
What is the expected output? What do you see instead?
I expect libmpsse installed. So I can run "make example-code". But it shows
"install -D -m644 libmpsse.so //usr/local/lib/libmpsse.so; install: accessing
'//usr/local/lib/libmpsse.so': No such host or network path make: [install]
Error 1"
What version of the product are you using? On what operating system?
libftdi1-1.0_devkit_mingw32_17Feb2013
libmpsse-1.3
Windows8
MinGW with mingw32
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 12 Dec 2013 at 10:02
I try to communicate with the MCP3202 A/D converter. This converter from
Microchip has an SPI interface and, according to the documentation, at the
begginning of communication I've to send 4 bits to the A/D in order to select
the input analog channel, set the bit-ordering mode, etc. After sending these 4
bits, subsequential 13 clock cycles will output a null bit and the 12 bits of
the converted value.
So, using the "write" function is not an option because as far as I know this
function sends only a byte at a time, and I must write only 4 bits to the chip,
not an entire byte. Is there any way to do so with libmpsse? or I've to modify
it?
For the sake of reference, this A/D chip is part of a DLP-2232DAQ board. I've
managed yet to communicate with the I/O ports included there thanks your great
libmpsse, so thank you for your work!
Original issue reported on code.google.com by [email protected]
on 5 Mar 2013 at 3:21
What steps will reproduce the problem?
1. Using an FTDI C232HM-DDHSL-0, USB to MPSSE cable connecting Linux server to
I2C/SMBus/PMBus power supply
2. Repeating many times, command the power supply to provide a data value
3. Read a known 16 bit data value from the power supply
4. Observe the I2C traffic with a scope
What is the expected output? What do you see instead?
We expect 0xC6 0x00, and get it about 99% of the time. About 1% of the time the
we see 0xC6 0x02 or 0xC6 0x08. And extra bit, always only one extra bit, is set
in the byte that should be 0x00. When we look at the data with the scope, the
bad values appear to be good clean representations of 0x00.
What version of the product are you using? On what operating system?
libmpsse 1.3, using the C interface, CentOS 6.4.
Please provide any additional information below.
There're obviously many ways this could be a system problem having nothing to
do with libmpsse. But I wonder if anyone has seen something similar.
thanks, Michael
Original issue reported on code.google.com by [email protected]
on 6 Jun 2014 at 6:11
What steps will reproduce the problem?
1. configure
2. make
What is the expected output? What do you see instead?
[molli123@c64 src]$ make
gcc -Wall -g -O2 -lftdi -c support.c
gcc -Wall -g -O2 -lftdi -c mpsse.c
gcc -shared -Wl,-soname,libmpsse.so mpsse.o support.o -o libmpsse.so -lftdi
/usr/bin/ld: mpsse.o: relocation R_X86_64_32 against `mpsse' can not be used
when making a shared object; recompile with -fPIC
mpsse.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [mpsse] Error 1
What version of the product are you using? On what operating system?
Version 0.2 on Fedora16
Please provide any additional information below.
simply adding -fPIC to CFLAGS in Makefile is not sufficient since not all CC
lines in Makefiles are using it ($(CC) -c $(TARGET)_wrap.c $(INC))
Original issue reported on code.google.com by [email protected]
on 20 Nov 2011 at 10:37
USB VID and PID values are not set when opening a device.
Original issue reported on code.google.com by [email protected]
on 25 Nov 2011 at 2:30
Attachments:
What steps will reproduce the problem?
1. Plug in an FTDI device with multiple interfaces (e.g. FT2232H w/IFACE_A,
IFACE_B)
2. Connect to the first one (successfully), using e.g. SPI:
mpsseA = OpenIndex(0x0403, 0x6014, SPI0, ONE_MHZ, MSB, IFACE_A, NULL, NULL, 0);
3. Connect to the second one (won't work), using e.g. SPI:
mpsseB = OpenIndex(0x0403, 0x6014, SPI0, ONE_MHZ, MSB, IFACE_B, NULL, NULL, 0);
4. Notice 2nd connection did not work:
(mpsseB == NULL)
What is the expected output? What do you see instead?
Ideally both connections would be valid, up-and-running and I could talk to 2
separate SPI circuits independently (and/or simultaneously). Instead the second
connection failed
What version of the product are you using? On what operating system?
Latest SVN as of today (r201), same as libftdi. Using OS X 10.8.4.
Please provide any additional information below.
Asking for IFACE_B first, and then IFACE_A, confirms that the interface
parameter works, but once I have made the first USB connection (e.g. to
IFACE_B), I cannot make a 2nd connection to the other interface (IFACE_A in
this case)
Original issue reported on code.google.com by [email protected]
on 9 Jul 2013 at 9:20
What steps will reproduce the problem?
Using the following python:
from mpsse import *
a = MPSSE()
c = MPSSE()
a.Open(0x403, 0x6011, SPI0, ONE_MHZ, MSB, IFACE_A)
c.Open(0x403, 0x6011, GPIO, ONE_MHZ, MSB, IFACE_C)
c.Stop()
c.PinHigh(7)
What is the expected output?
On my board, the GPIO of port C (pin 7 in this case) is hooked up to a chip
select. So I need to be able
to toggle this to access the SPI on port A (which will eventually be JTAG, but
it starts of as SPI). There is
an LED attached which goes on and off when you change the pin high and low.
What do you see instead? Nothing happens.
What version of the product are you using? Latest SVN (doesn't have the patch
to clear errors when
you start.)
what operating system? Ubuntu 12.10 LTS
Please provide any additional information below.
I could be misusing the GPIO functionality, but it didn't seem to work. I have
a patch, which I attached, which adds "BITBANG". I added this because I was
afraid I was missing something when I looked at what GPIO was doing and did not
want to change GPIO if I misunderstood it. But it appears that if you use
GPIO, it doesn't really do anything. I traced why at one point, created the
patch, and promptly forgot why. At any rate, the BITBANG functionality seems
to do what I needed to do (or at least make PinHigh/PinLow function as I
expected they would).
Original issue reported on code.google.com by [email protected]
on 12 Jul 2012 at 2:07
Attachments:
Latest libftdi puts the ftdi.h file in libftdi/ftdi.h. Add a check for this in
the configure script.
Original issue reported on code.google.com by [email protected]
on 28 Jan 2013 at 6:38
What steps will reproduce the problem?
1. Build and install libftdi1 to /home/cmorgan/local_install
2. Run configure in libmpsse with:
./configure --prefix=/home/cmorgan/local_install CFLAGS="-I
/home/cmorgan/local_install/include -fPIC" LDFLAGS="-L
/home/cmorgan/local_install/lib64"
3. Output is:
checking for GNU libc compatible malloc... yes
checking libftdi1/ftdi.h usability... yes
checking libftdi1/ftdi.h presence... no
configure: WARNING: libftdi1/ftdi.h: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: libftdi1/ftdi.h: proceeding with the compiler's result
checking for libftdi1/ftdi.h... yes
checking for ftdi_init in -lftdi1... yes
checking /usr/include/python2.7/Python.h usability... yes
checking /usr/include/python2.7/Python.h presence... yes
checking for /usr/include/python2.7/Python.h... yes
configure: creating ./config.status
config.status: creating Makefile
I looked in config.log:
configure:3355: gcc -c -Wall -fPIC -fno-strict-aliasing -I
/home/cmorgan/local_install
configure:3355: $? = 0
configure:3355: result: yes
configure:3355: checking libftdi1/ftdi.h presence
configure:3355: gcc -E conftest.c
conftest.c:21:27: fatal error: libftdi1/ftdi.h: No such file or directory
#include <libftdi1/ftdi.h>
^
compilation terminated.
I have no idea why CFLAGS isn't being used in the compile check. Is there some
way to specify the path to libftdi1 via a configure option?
Original issue reported on code.google.com by [email protected]
on 13 Sep 2013 at 8:18
FastTransfer is called with pointer to a non empty output buffer, and an input
buffer, transfer size : 2 bytes.
Expecting a 2-byte SPI transaction, but only the start and stop condition (CS
going down and then up) appear on a logic analyzer.
Function returns MPSSE_FAIL.
Code :
uint8_t outbuf[2];
uint8_t inbuf[2];
[...]
outbuf[0] = READ_ACCESS | (address & 0x7F);
outbuf[1] = 0x00;
i = Start(mpsse);
j = FastTransfer(mpsse, (char *)outbuf, (char *)inbuf, 2);
k = Stop(mpsse);
Using libmpsse 1.3 with a FT2232H on a Linux ARM system (Pcduino).
An similar subroutine calling
j = FastWrite(mpsse, (char *)outbuf, 2);
is working properly.
Original issue reported on code.google.com by [email protected]
on 24 Jul 2013 at 7:18
I have multiple devices identifying with the standard FTDI pid and vid, since
our organisation does not have an own vendor id.
The devices (different versions of a PCB) identify themselves with different
product descriptions, carrying a board revision. Therefore, selectively opening
a device on the basis of the board version was needed, since serial numbers are
unique per board version only.
See the attached .diff files for the modification. NOTE that the modification
breaks the API.
Original issue reported on code.google.com by [email protected]
on 5 Apr 2012 at 9:42
Attachments:
What steps will reproduce the problem?
1.
2.
3.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 18 Sep 2014 at 11:15
What steps will reproduce the problem?
1. Any call to WritePins fails
What is the expected output? What do you see instead?
Get an MPSSE_FAIL for return value instead of MPSSE_OK
What version of the product are you using? On what operating system?
latest SVN version.
Please provide any additional information below.
I looked at this and found, much to my chagrin, that when I'd given you this
function, I was only checking for ftdi_write_data to return 0. The latest
libftdi version doesn't do that. It actually returns the number of bytes
written, in which case the following:
if(ftdi_write_data(&mpsse->ftdi, &data, 1) == 0)
will always fail, even if there is a success. It probably should read:
if(ftdi_write_data(&mpsse->ftdi, &data, 1) > 0)
I guess it could even read:
if(ftdi_write_data(&mpsse->ftdi, &data, 1) >= 0)
I would send a patch instead, but I made the change without creating a git
repository. Since it was a trivial change, it is no big deal. I'm guessing
not too many people use this function. I don't know if, given some of the
library additions, there is now a better, or different way to achieve what this
achieved.
Thanks for taking a look.
Original issue reported on code.google.com by [email protected]
on 29 Nov 2013 at 4:05
I noticed that the memory usage started to rise exponentially when i disconnect
the device from the host. The software tries to reconnect to the device by
calling the Open method.
To reproduce the issue i ran the following code:
#include <mpsse.h>
#include <mcheck.h>
int main()
{
mtrace();
struct mpsse_context *Dev = Open(0x0403, 0x6014, I2C, ONE_HUNDRED_KHZ, MSB, IFACE_A, NULL, NULL);
Stop(Dev);
Close(Dev);
Dev = NULL;
muntrace();
}
The trace log:
Memory not freed:
-----------------
Address Size Caller
0x0000000000137da8 0x128 at ./lib/libusb/libusb/core.c:1594
0x0000000000137ed8 0x10 at ./lib/libusb/libusb/io.c:2323
0x0000000000137ef0 0x10 at ./lib/libusb/libusb/io.c:2323
0x0000000000137f08 0x18 at ./lib/libusb-compat/libusb/core.c:523
0x0000000000137f28 0 at ./lib/libusb-compat/libusb/core.c:420
0x0000000000137f38 0x5 at ./lib/libusb/libusb/os/linux_usbfs.c:868
0x0000000000137f48 0x4 at ./lib/libusb/libusb/os/linux_usbfs.c:868
0x0000000000137f58 0x1018 at ./lib/libusb-compat/libusb/core.c:217
0x0000000000138f98 0x1034 at ./lib/libusb-compat/libusb/core.c:330
0x0000000000139fd0 0x1034 at ./lib/libusb-compat/libusb/core.c:330
0x000000000013b008 0x1034 at ./lib/libusb-compat/libusb/core.c:330
0x000000000013c040 0x1034 at ./lib/libusb-compat/libusb/core.c:330
0x000000000013d078 0x1034 at ./lib/libusb-compat/libusb/core.c:330
0x000000000013e0b0 0x1034 at ./lib/libusb-compat/libusb/core.c:330
0x000000000013f0e8 0x18 at ./lib/libusb-compat/libusb/core.c:523
0x000000000013f108 0x28 at ./lib/libusb-compat/libusb/core.c:420
0x000000000013f138 0x18 at ./lib/libusb-compat/libusb/core.c:523
0x000000000013f158 0x8 at ./lib/libusb-compat/libusb/core.c:479
0x000000000013f198 0x8 at ./lib/libusb-compat/libusb/core.c:479
0x000000000013f1a8 0x18 at ./lib/libusb-compat/libusb/core.c:454
0x000000000013f1c8 0x9 at ./lib/libusb-compat/libusb/core.c:435
0x000000000013f200 0x18 at ./lib/libusb-compat/libusb/core.c:523
0x000000000013f220 0x18 at ./lib/libusb-compat/libusb/core.c:454
0x000000000013f240 0x28 at ./lib/libusb-compat/libusb/core.c:420
0x000000000013f270 0x18 at ./lib/libusb-compat/libusb/core.c:454
0x000000000013f290 0x18 at ./lib/libusb-compat/libusb/core.c:523
0x000000000013f2c8 0x8 at ./lib/libusb-compat/libusb/core.c:479
0x000000000013f2d8 0x14 at ./lib/libusb-compat/libusb/core.c:420
0x000000000013f2f0 0x10 at ./lib/libusb-compat/libusb/core.c:479
0x000000000013f308 0x18 at ./lib/libusb-compat/libusb/core.c:454
0x000000000013f328 0x14 at ./lib/libusb-compat/libusb/core.c:420
0x000000000013f348 0x18 at ./lib/libusb-compat/libusb/core.c:523
0x000000000013f368 0x18 at ./lib/libusb-compat/libusb/core.c:454
0x000000000013f388 0x14 at ./lib/libusb-compat/libusb/core.c:420
0x000000000013f3d8 0x17 at ./lib/libusb-compat/libusb/core.c:435
0x000000000013f3f8 0x30 at ./lib/libusb-compat/libusb/core.c:454
0x000000000013f430 0x28 at ./lib/libusb-compat/libusb/core.c:420
0x000000000013f490 0x8 at ./lib/libusb-compat/libusb/core.c:479
0x000000000013f4a0 0x18 at ./lib/libusb-compat/libusb/core.c:454
0x000000000013f4e0 0x8 at ./lib/libusb-compat/libusb/core.c:479
0x000000000013f4f0 0x14 at ./lib/libusb-compat/libusb/core.c:420
0x0000000000140f98 0x40 at ./lib/libusb/libusb/core.c:533
0x0000000000140fe0 0x40 at ./lib/libusb/libusb/core.c:533
0x0000000000141028 0x40 at ./lib/libusb/libusb/core.c:533
0x0000000000141070 0x6 at ./lib/libusb/libusb/os/linux_usbfs.c:868
0x0000000000141080 0x40 at ./lib/libusb/libusb/core.c:533
0x00000000001410c8 0x6 at ./lib/libusb/libusb/os/linux_usbfs.c:868
0x00000000001410d8 0x40 at ./lib/libusb/libusb/core.c:533
0x0000000000141120 0x8 at ./lib/libusb/libusb/os/linux_usbfs.c:868
0x0000000000141130 0x40 at ./lib/libusb/libusb/core.c:533
0x0000000000141178 0x8 at ./lib/libusb/libusb/os/linux_usbfs.c:868
What am i forgetting to do? Is this an upstream bug?
Original issue reported on code.google.com by [email protected]
on 6 Sep 2013 at 12:39
ftdi_set_interface() should be called before ftdi_usb_open_desc()
The current version does this the other way around, which means that libftdi
will open INTERFACE_A first, then switch to the one passed to Open().
This causes problems if one uses INTERFACE_A for other purposes, spams the
kernel logs with "did not claim interface X before use", and IIRC will error
out with libftdi-1.
Original issue reported on code.google.com by [email protected]
on 26 Feb 2012 at 9:07
What steps will reproduce the problem?
1. Build code against libftdi1 installed to non-system directory
2. Call make with the path to the include/ that contains libftdi1/
2. Compilation will fail at fast.o
make CFLAGS="-I/home/cmorgan/local_install/include -fPIC"
...
gcc -I/home/cmorgan/local_install/include -fPIC -lftdi1 -L
/home/cmorgan/local_install/lib64 -c fast.c
In file included from fast.c:10:0:
mpsse.h:9:18: fatal error: ftdi.h: No such file or directory
#include <ftdi.h>
^
compilation terminated.
make: *** [fast.o] Error 1
3. Modify the make line to include the libftdi1 directory like:
make CFLAGS="-I/home/cmorgan/local_install/include/libftdi1 -fPIC"
4. Now other files will fail to compile like:
n/local_install/lib64 -DSWIGPYTHON -DLIBFTDI1=1 -c support.c
support.c:11:27: fatal error: libftdi1/ftdi.h: No such file or directory
#include <libftdi1/ftdi.h>
^
compilation terminated.
5.Go back to the original make line to finish the compile:
make CFLAGS="-I/home/cmorgan/local_install/include -fPIC"
The issue appears to be this in the makefile:
mpsse.o: support.o
$(CC) $(CFLAGS) $(LDFLAGS) -DLIBFTDI1=$(LIBFTDI1) -c mpsse.c
fast.o: support.o
$(CC) $(CFLAGS) $(LDFLAGS) -c fast.c <------------ Lack of LIBFTDI1 define
support.o:
$(CC) $(CFLAGS) $(LDFLAGS) -DLIBFTDI1=$(LIBFTDI1) -c support.c
When fast.o is being built fast.c is compiled which eventually includes mpsse.h
which looks for the 0.x series libftdi headers like <ftdi.h> instead of
<libftdi1/ftdi.h>.
Modifying Makefile.in to go from:
fast.o: support.o
$(CC) $(CFLAGS) $(LDFLAGS) -c fast.c
to:
fast.o: support.o
$(CC) $(CFLAGS) $(LDFLAGS) -DLIBFTDI1=$(LIBFTDI1) -c fast.c
Fixes the issue here.
I can submit a patch or test etc, just email me, [email protected]
Original issue reported on code.google.com by [email protected]
on 13 Sep 2013 at 9:35
I'm trying to build libmpsse trunk (r202) out-of-source. So something like:
cd somedirectory
../../../libmpsse/src/configure --prefix=/local_install_directory
CFLAGS="-I/myotherrootfs" LDFLAGS="-L/myotherrootfs/lib64"
Configure succeeds and generates a makefile but the file names are all relative
to the original source directory.
This looks to come directly from Makefile.in (I'm not super familiar with
autotools at this point):
mpsse.o: support.o
$(CC) $(CFLAGS) $(LDFLAGS) -DLIBFTDI1=$(LIBFTDI1) -c mpsse.c
I've started to modify the Makefile.in to use ${srcdir) etc but I'm wondering
if you would be opposed to switching to cmake. Libftdi uses it for their build
system and I suspect it would make it much easier to handle things like this.
It would also make it easier to detect libftdi, there is a helpful cmake script
that libftdi installs that will retrieve the libraries and include paths.
I could provide the CMakeLists.txt file if that would be helpful as I need to
integrate this into our build system and we try hard to perform out-of-source
builds.
[email protected] if you want to get ahold of me.
Original issue reported on code.google.com by [email protected]
on 14 Oct 2013 at 1:14
Hello
I installed all the needed Packages including libftdi1
but it still comes up with a fault
i extractet the header files from the FT Folder to setup folder but no luck
where i should put the files?
Here a part from the Log
checking for /usr/include/python2.7/Python.h... yes
configure: creating ./config.status
config.status: creating Makefile
gcc -Wall -fPIC -fno-strict-aliasing -g -O2 -lftdi1 -c fast.c
In file included from fast.c:10:0:
mpsse.h:9:18: fatal error: ftdi.h: No such file or directory
#include <ftdi.h>
^
compilation terminated.
make: *** [fast.o] Error 1
System Debian x64
Regards,
Al
Original issue reported on code.google.com by [email protected]
on 4 Mar 2014 at 1:51
Attachments:
What steps will reproduce the problem?
1. open the terminal
2. super user
3. extract the file
4. go into the src folder
5. run ./configure in the terminal
What is the expected output?
Checking for malloc… no
Configure: error: “missing standard functions”
What do you see instead?
Checking for malloc… yes
What version of the product are you using? On what operating system?
libmpsse-1.2-1, fedora 16
Please provide any additional information below.
I had installed the glibc and also the gcc.
Original issue reported on code.google.com by [email protected]
on 26 Dec 2012 at 8:41
It's not really a problem, but I'm rather perplexed as to how to talk to specific I2C slaves. I only saw the i2ceeprom example, which somehow doesn't seem like what I need.
I basically have an I2C slave on address 0x48 (it's an A->D converter, but that doesn't really matter). Later on I'll also add another I2C slave on the same line, so I really need to specify the proper addresses to talk to them.
So how could I do something like:
#define ADS1015_REG_POINTER_CONFIG (0x01)
#define ADS1015_REG_POINTER_CONVERT (0x00)
int Address=0x48;
ioctl(i2cFile, I2C_SLAVE, Address);
i2c_smbus_write_word_data(i2cFile,ADS1015_REG_POINTER_CONFIG,0x1122);
i2c_smbus_read_word_data(i2cFile,ADS1015_REG_POINTER_CONVERT);
with libmpsse?
Original issue reported on code.google.com by [email protected]
on 10 Mar 2014 at 8:51
What steps will reproduce the problem?
1. read data using raw_read() or Read() or Transfer()
What is the expected output? What do you see instead?
Fast response. Delayed response.
What version of the product are you using? On what operating system?
libmpsse 1.2 Mac OS X
Please provide any additional information below.
/* Make sure the buffers are cleared after a read or subsequent reads may fail */
ftdi_usb_purge_rx_buffer(&mpsse->ftdi);
ftdi_usb_purge_tx_buffer(&mpsse->ftdi);
ftdi_usb_purge_buffers(&mpsse->ftdi);
ftdi_usb_purge_buffers already clears both of the buffers by calling
ftdi_usb_purge_rx_buffer and ftdi_usb_purge_tx_buffer. In my use of libmpsse
using SPI, a purge buffer command is not even needed at all.
Original issue reported on code.google.com by [email protected]
on 31 Jan 2013 at 5:43
What steps will reproduce the problem?
1. run configure
2. run make
What is the expected output? What do you see instead?
A built lib
What version of the product are you using? On what operating system?
Linux version 2.6.38-8-generic (buildd@allspice) (gcc version 4.5.2
(Ubuntu/Linaro 4.5.2-8ubuntu3) ) #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011
gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
Please provide any additional information below.
Please see patch.
Original issue reported on code.google.com by [email protected]
on 24 Nov 2011 at 9:09
Attachments:
What steps will reproduce the problem?
1. Tested with SFP optical transceiver, although it might be reproducible using
EEPROMs. Adapt the i2ceeprom example code to read a block of data from an I2C
peripheral device.
2. Run the example with the peripheral device. Verify it reads meaningful data.
3. Then, rerun the example without resetting the peripheral.
What is the expected output? What do you see instead?
Depending on the data contents being read, in some cases the peripheral will
fail the second read, usually returning all 0xFF bytes.
What version of the product are you using? On what operating system?
SVN version as of 02/27/2012, OS is CentOS 6.2 with libftdi1 and libusb1.
Please provide any additional information below.
Scope shows that the error is caused by the peripheral device's failure to
release control of the SDA line after we are finished reading from it. When the
problem occurs, the SDA line remains pulled low, as is the peripheral is trying
to clock out more data for the master. That is indeed the case. The problem is
caused by the build_block_buffer() function in support.c module, which ends the
final byte read from I2C with ACK instead of NACK. See the recommendation at
http://www.nxp.com/documents/user_manual/UM10204.pdf chapter 3.1.6: "...When
SDA remains HIGH during this ninth clock pulse, this is defined as the Not
Acknowledge signal. The master can then generate either a STOP condition to
abort the transfer, or a repeated START condition to start a new transfer."
Patching the support.c to include something like this at line 169:
//buf[i++] = mpsse->tack;
buf[i++] = (j < num_blocks - 1) ? 0x00 : 0xFF; //NACK the last byte
resolves the problem, at least in my case. The STOP sequence is then properly
executed and the program can be successfully restarted many times without
resetting the peripheral.
Original issue reported on code.google.com by [email protected]
on 27 Feb 2012 at 7:50
In file included from fast.c:10:0:
mpsse.h:9:18: fatal error: ftdi.h: No such file or directory
Makefile.in seems to not be passing LIBFTDI1 define when compiling fast.c.
Patch attached.
Original issue reported on code.google.com by [email protected]
on 28 May 2013 at 1:35
Attachments:
What steps will reproduce the problem?
1. Use PC to install mingw with msys shell.
2. install libftdi1-1.0_devkit_mingw32_17Feb2013.zip
3. install libmpsse-1.3.
4. use C232HM USB 2.0 Hi-Speed to MPSSE cable.
What is the expected output? What do you see instead?
Should work.
After run spiflash.exe, shows "Failed to initialize MPSSE: device not found"
What version of the product are you using? On what operating system?
libmpsse-1.3 on windows8 mingw.
Please provide any additional information below.
Issue24 has the same issue. But I don't know how to run as root in mingw msys
shell.
Original issue reported on code.google.com by [email protected]
on 16 Dec 2013 at 10:30
What steps will reproduce the problem?
1. Open in I2C mode
2. Issue start condition (call Start() method)
I found a bug in Start() method.
See the attached patch file.
Original issue reported on code.google.com by [email protected]
on 19 Sep 2012 at 9:58
Attachments:
What steps will reproduce the problem?
1. SPI transfer with + 1024 bytes
What is the expected output? What do you see instead?
Its blocking... I expect a result :-)
What version of the product are you using? On what operating system?
libmpsse-1.2-1
Linux lars-pc 3.5.0-22-generic #34-Ubuntu SMP Tue Jan 8 21:47:00 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux
Please provide any additional information below.
There is a bug inside the Transfer function.
Also I had to decrease the SPI_TRANSFER_SIZE.
diff --git a/spi/mpsse.c b/spi/mpsse.c
index 8347b0b..dca3cee 100644
@@ -767,14 +767,14 @@ char *Transfer(struct mpsse_context *mpsse, char *data,
int size)
memset(buf, 0, size);
/* When sending and recieving, FTDI chips don't seem to like large data blocks. Limit the size of each block to SPI_TRANSFER_SIZE */
- rxsize = size - n;
- if(rxsize > SPI_TRANSFER_SIZE)
- {
- rxsize = SPI_TRANSFER_SIZE;
- }
while(n < size)
{
+ rxsize = size - n;
+ if(rxsize > SPI_TRANSFER_SIZE)
+ {
+ rxsize = SPI_TRANSFER_SIZE;
+ }
txdata = build_block_buffer(mpsse, mpsse->txrx, (unsigned char *) (data + n), rxsize, &data_size);
if(txdata)
{
diff --git a/spi/mpsse.h b/spi/mpsse.h
index cc6da43..1c8234f 100644
@@ -12,7 +12,7 @@
#define CHUNK_SIZE 65535
#define SPI_RW_SIZE (63 * 1024)
-#define SPI_TRANSFER_SIZE 1024
+#define SPI_TRANSFER_SIZE 512
#define I2C_TRANSFER_SIZE 64
#define LATENCY_MS 2
Original issue reported on code.google.com by [email protected]
on 2 Feb 2013 at 10:34
What steps will reproduce the problem?
1. Set MPSSE.SPI.Open(SPI1, ***, MSB) or MPSSE.SPI.Open(SPI3, ***, MSB)
2. Attach scope to SCLK, MOSI and CS lines
3. Write one byte
What is the expected output? What do you see instead?
8 clock cycles are expected on SCLK, but another clock edge appears at the end
of the transmission: this edge appears BEFORE CS goes high, thus it is received
by any guest device present on the SPI bus, causing it to shift its internal
register once more.
In SPI mode 1 the clock should remain low after the last (8th) falling edge,
while in SPI mode 3 the clock should remain high after the 8th rising edge.
Modes 0 and 2 operate correctly.
What version of the product are you using? On what operating system?
Using r122 from svn (same problem happens with release 1.2-1), host device is a
C232HM cable equipped with a FTDI232H IC.
OS is gentoo x86-64, libftdi 0.20
Please provide any additional information below.
I was trying to communicate with an AD5293, that supports only SPI mode 1. Word
size is 2 Bytes.
The device was ignoring all the commands.
After analyzing the data coming out of MISO, I realized that the read-back word
was the same I'd input, only shifted one position.
Using the scope I was able to verify that another clock edge indeed appears on
SCLK before the chip select is removed (a rising edge, in this case), the clock
then proceeds to remain high until the end of the transmission (even if it's
supposed to idle low in mode 1).
SPI mode 1 devices are supposed to clock out the MSB of their internal register
on the rising edge of SCLK, therefore the additional clock edge effectively
shifts the guest device internal register, making the command invalid.
Also, some devices (like the AD5293) have an internal counter attached to SCLK
and, if the count is not an exact multiple of the word size, they will ignore
the received data altogether (which is what happens in my case, since the
device counts 17 clock cycles).
Digging into mpsse.c, I stumbled upon the comment on line 381, which at first
sight seemed to be the source of my problems.
I tried to replace {mpsse->pstop |= SK} with {mpsse->pstop &= ~SK}, hoping that
would solve the issue, but this change has no effect whatsoever: the clock
keeps going high at the end of the transmission.
I've verified that the opposite thing is happening in mode 3: in this case, the
clock goes low before the chip select is removed, adding a 9th (falling) clock
edge.
The behavior persists even if I change the pstop condition on mpsse.c:369.
Original issue reported on code.google.com by [email protected]
on 5 Dec 2012 at 7:14
Feature needed: If multiple FTDI devices are attached there is no mechanism
provided by the libmpsse to allow the user to specify the adapter index to be
used. The serial number is not sufficient since there are chips that don't have
the serial number set to an unique number.
Attached is a possible patch against libmpsse-1.2-1.tar.gz for implementing
this feature.
Original issue reported on code.google.com by [email protected]
on 23 Jan 2013 at 1:55
Attachments:
What steps will reproduce the problem?
1. Using an SPI MCP4262, Send a read command through either python or c code...
2. Try to read the value during the write cycle
For example:
from mpsse import *
spi = MPSSE(SPI0, 250000)
spi.Start()
spi.Write('\x5F\xFF')
spi.Stop()
spi.Read(2)
What is the expected output? What do you see instead?
No matter what combination of writes and reads you try, you cannot get the data
sent
during the write cycle. In this case, you should see \xFF\xE0 on a default
chip.
What version of the product are you using? On what operating system?
libmpsse-1.1
Please provide any additional information below.
It is possibly a libftdi problem, since the interface doesn't seem to be
exposed to access the read fifo from the FTDI chip. Maybe adding in some
access in libftdi or some direct USB access to that data.
The biggest problem is that most people are using "fake" SPI devices which
support Write then Read.
The SPI protocol should support Reading the data while writing as it is part of
the spec and the FTDI
chip does seem to support it.
Original issue reported on code.google.com by [email protected]
on 17 May 2012 at 4:00
What steps will reproduce the problem?
1. "./configure" fails
This problem is related to my previous response on another issue:
https://code.google.com/p/libmpsse/issues/detail?id=32#c2
For Mac OS X + MacPorts, it seems that there is an easier way to globally
enable (custom) builds to use the "/opt/local" in the search path of compiler.
edit your environment settings (eg. "/etc/profile") and append:
export LDFLAGS="-L/opt/local/lib"
export CFLAGS="-I/opt/local/include"
export CPPFLAGS="-I/opt/local/include"
Remember to (re)open a new terminal for the changes to take effect and then it
works just fine to execute the default configure:
------------------------------------------
$ ./configure
------------------------------------------
Although it actually might make sense to update the install path for libmpsse
accordingly:
------------------------------------------
$ ./configure --prefix=/opt/local/
------------------------------------------
Next, to be able to run "make install" in OS X, the "-D" option should not
present in the Makefile. So replace all "install -D ..." to "install ..." and
you can install it without a problem.
------------------------------------------
$ sudo make install
------------------------------------------
I'm not sure if the "-D" option is necessary for other unix systems like
linux/bsd, otherwise it might be a suggestion to just remove this directive
from the "Makefile.in" in the current repository.
Last issue I ran into is compiling the examples afterwards.
The Makefile in the "libmpsse/src/examples" directory currently does not work
with globally defined compile and linker flags.
------------------------------------------
$ cd libmpsse/src/examples
$ make
------------------------------------------
cc -I/opt/local/include spiflash.c -o spiflash -lmpsse
ld: library not found for -lmpsse
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [spiflash] Error 1
------------------------------------------
However, when we patch the first line of "libmpsse/src/examples/Makefile":
"LDFLAGS=-lmpsse" -> "LDFLAGS+=-lmpsse"
Then it works just fine!
------------------------------------------
$ cd libmpsse/src/examples
$ make
------------------------------------------
cc -I/opt/local/include spiflash.c -o spiflash -L/opt/local/lib -lmpsse
cc -I/opt/local/include spiflashfast.c -o spiflashfast -L/opt/local/lib -lmpsse
cc -I/opt/local/include i2ceeprom.c -o i2ceeprom -L/opt/local/lib -lmpsse
cc -I/opt/local/include ds1305.c -o ds1305 -L/opt/local/lib -lmpsse
cc -I/opt/local/include gpio.c -o gpio -L/opt/local/lib -lmpsse
cc -I/opt/local/include bitbang.c -o bitbang -L/opt/local/lib -lmpsse
------------------------------------------
Also this patch might be useful to actually embed into the repository.
Original issue reported on code.google.com by verdult
on 19 Aug 2014 at 8:28
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.