read problem

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

read problem

Rob Coker

I'm trying to communicate to a device that uses an FTDI 232 chip from a Gumstix Airstorm Overo COM (Cortex-A8 CPU) on a custom base board using meta-embedded as the Linux distro.  I built/installed libftdi for this.  I already had libusb 1.x installed.  When I connect the device, it shows up in lsusb.  I'm able to use libusb calls to open it and query the serial number.  All that works.  When I send data, it seems to be successful (no error on libusb transfer call, bytesWritten is correct), but receiving data is not.  All I get is the 2 modem status bytes back which libftdi seems to always return.  At one point I received a partial message that was correct, but the last byte or two of the message was dropped.

I am pretty sure about my endpoints and transfer mode based on the output of lsusb -v.

I have a number of related questions:
1. Is there an incompatibility between libusb and libftdi?  Particularly this could center around libftdi returning modem status and libusb thinking that's the whole message to receive.  Is there a way around this?

2. Would going to libftdi 1.2 fix anything?
3. Would it make sense to interact with libftdi directly?

4. I can get lots of libusb debug info.  Is there a way to get libftdi specific debug info when making calls through libusb?

 

Some of these questions may be better for the libusb forum, but this seemed the best place to start.  I've also posted on the gumstix forum.

Thanks,
Rob



libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: read problem

Uwe Bonnes
>>>>> "Rob" == Rob Coker <[hidden email]> writes:

    Rob> I'm trying to communicate to a device that uses an FTDI 232 chip
    Rob> from a Gumstix Airstorm Overo COM (Cortex-A8 CPU) on a custom base
    Rob> board using meta-embedded as the Linux distro.  I built/installed
    Rob> libftdi for this.  I already had libusb 1.x installed.  When I
    Rob> connect the device, it shows up in lsusb.  I'm able to use libusb
    Rob> calls to open it and query the serial number.  All that works.
    Rob> When I send data, it seems to be successful (no error on libusb
    Rob> transfer call, bytesWritten is correct), but receiving data is not.
    Rob> All I get is the 2 modem status bytes back which libftdi seems to
    Rob> always return.  At one point I received a partial message that was
    Rob> correct, but the last byte or two of the message was dropped.

    Rob> I am pretty sure about my endpoints and transfer mode based on the
    Rob> output of lsusb -v.

    Rob> I have a number of related questions: 1. Is there an
    Rob> incompatibility between libusb and libftdi?  Particularly this
    Rob> could center around libftdi returning modem status and libusb
    Rob> thinking that's the whole message to receive.  Is there a way
    Rob> around this?

    Rob> 2. Would going to libftdi 1.2 fix anything?  3. Would it make sense
    Rob> to interact with libftdi directly?

    Rob> 4. I can get lots of libusb debug info.  Is there a way to get
    Rob> libftdi specific debug info when making calls through libusb?

    Rob> Some of these questions may be better for the libusb forum, but
    Rob> this seemed the best place to start.  I've also posted on the
    Rob> gumstix forum.

Did you check the physical layer on the TX/RX lines. Are there signals
as you expected? Can you decode with a logic analyser?

Otherwise recent libftdi also uses libusb, but libftdi was not updated for
about 3 years with update intentions denied. So newer parts are not
supported.

But if things don't work one way, trying another way may be an option.

Bye

--
Uwe Bonnes                [hidden email]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: read problem

Thomas Jarosch
On Wednesday, 15. April 2015 11:12:41 Uwe Bonnes wrote:
> Otherwise recent libftdi also uses libusb, but libftdi was not updated for
> about 3 years with update intentions denied. So newer parts are not
> supported.

Just to clarify: That paragraph refers to libftdi 0.x using libusb 0.x.

Newer libftdi1 1.x of course is updated for new parts.

Cheers,
Thomas


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: read problem

Uwe Bonnes
>>>>> "Thomas" == Thomas Jarosch <[hidden email]> writes:

    Thomas> On Wednesday, 15. April 2015 11:12:41 Uwe Bonnes wrote:
    >> Otherwise recent libftdi also uses libusb, but libftdi was not
    >> updated for about 3 years with update intentions denied. So newer
    >> parts are not supported.

    Thomas> Just to clarify: That paragraph refers to libftdi 0.x using
    Thomas> libusb 0.x.

    Thomas> Newer libftdi1 1.x of course is updated for new parts.

    Thomas> Cheers, Thomas

Argh, didn't recheck the Mail and mixed up libftd2xx and libftdi :-(

I meant the manufacturer FTD2XX dll was not update for years. Thomas keeps
libftdi recent, so I am very sorry for the wrong statement.

Bye
--
Uwe Bonnes                [hidden email]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Re: read problem

Rob Coker
I think the key issue is that I had the dependencies backward.  I should be
interfacing with libftdi, not libusb, to get it to work.  I thought libftdi
was a driver/plugin for libusb, so I should interface libusb and it would go
through libftdi.  But as you helpfully pointed out, that's completely
backwards.

Thanks for the help,
Rob

-----Original Message-----
From: Uwe Bonnes [mailto:[hidden email]]
Sent: Wednesday, April 15, 2015 6:17 AM
To: [hidden email]
Subject: Re: Re: read problem

>>>>> "Thomas" == Thomas Jarosch <[hidden email]> writes:

    Thomas> On Wednesday, 15. April 2015 11:12:41 Uwe Bonnes wrote:
    >> Otherwise recent libftdi also uses libusb, but libftdi was not
    >> updated for about 3 years with update intentions denied. So newer
    >> parts are not supported.

    Thomas> Just to clarify: That paragraph refers to libftdi 0.x using
    Thomas> libusb 0.x.

    Thomas> Newer libftdi1 1.x of course is updated for new parts.

    Thomas> Cheers, Thomas

Argh, didn't recheck the Mail and mixed up libftd2xx and libftdi :-(

I meant the manufacturer FTD2XX dll was not update for years. Thomas keeps
libftdi recent, so I am very sorry for the wrong statement.

Bye
--
Uwe Bonnes                [hidden email]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Re: read problem

Rob Coker
In reply to this post by Uwe Bonnes
Now that I understand the library dependencies and have fixed my code
accordingly, I'm still not getting read data.  Libftdi is stripping the
modem status bytes, so I don't get those either.  I'm pretty sure of my
physical layer because I've used other devices and am able to get the serial
number and related info using libusb or lsusb -v.  Open works and transmit
seems to (get correct number of bytes written back).  The read call is
returning immediately with no data, even though it looks like libftdi is
telling libusb to use a 5000 msec wait time.  

On windows using the proprietary ftd2xx.lib, the device works.  Do you know
what the baud rate (and other settings) are for that?  In other words, if I
were trying to mimic the ftd2xx lib, what baud rate and other settings
should I use.  I noticed the default in the open by device call was 9600
baud.  That's way slower than the data is coming across on the Windows side
since I'm receiving 260 kilobits every second and the link is not fully
utilized. Also, I'm assuming that ftd2xx.lib is not operating in bit-bang
mode in that case.  Is that a reasonable assumption?

Thanks,
Rob



--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Loading...