Date: Sun, 27 Sep 2009 01:05:42 -0400 From: Pierre-Luc Drouin <pldrouin@pldrouin.net> To: Hans Petter Selasky <hselasky@c2i.net>, ed@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT Message-ID: <4ABEF2A6.6010801@pldrouin.net> In-Reply-To: <200909230851.03442.hselasky@c2i.net> References: <4AB6DA79.7050209@pldrouin.net> <200909221847.26679.hselasky@c2i.net> <4AB915CE.8090503@pldrouin.net> <200909230851.03442.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hans Petter Selasky wrote: > On Tuesday 22 September 2009 20:22:06 Pierre-Luc Drouin wrote: > >> Hans Petter Selasky wrote: >> >>> On Tuesday 22 September 2009 18:40:40 Pierre-Luc Drouin wrote: >>> >>>> Hans Petter Selasky wrote: >>>> >>>>> On Tuesday 22 September 2009 18:15:19 Pierre-Luc Drouin wrote: >>>>> >>>>>> Hans Petter Selasky wrote: >>>>>> >>>>>>> On Tuesday 22 September 2009 17:21:28 Pierre-Luc Drouin wrote: >>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>> It indicates that your device is not sending any data. >>>>>>>>> >>>>>>>>> --HPS >>>>>>>>> >>>>>>>> So does it mean that the write statement (a status request) is not >>>>>>>> transmitted to the device either? >>>>>>>> >>>>>>> No, the "xxx_get()" message means that the data you write is sent and >>>>>>> transmitted. >>>>>>> >>>>>>> BTW: I have a FTDI adapter here, and it works fine with loopback when >>>>>>> the baudrate is set correctly. >>>>>>> >>>>>>> >>>>>>>> Because this write statement should be >>>>>>>> followed by data sent from the device and it effectively does on >>>>>>>> Linux. And about SIGIO, shouldn't this signal be generated only when >>>>>>>> there is data available to read? Why is it generated in asynchronous >>>>>>>> mode and then the read statement returns EINTR? >>>>>>>> >>>>>>> Ed has to answer these questions. This stuff is not handled in the >>>>>>> USB stack for FTDI devices. >>>>>>> >>>>>>> --HPS >>>>>>> >>>>>> In the manual page for the uftdi driver, the chip I am using (FT232BL) >>>>>> is not listed. According to the FTDI website, it is based on >>>>>> FT8U232AM, but it has extra functionalities. Have you had the chance >>>>>> to test an device that uses either a FT232BM, FT232BL or FT232BQ chip? >>>>>> I just tested the device on FreeBSD 7.2 and it does not work either... >>>>>> >>>>> No, I haven't. >>>>> >>>>> --HPS >>>>> >>>> Are there additional tests I can do in synchronous mode to try pinning >>>> down the problem? >>>> >>> Hi, >>> >>> If the device doesn't work, then there are probably some FTDI USB >>> registers which are not programmed correctly. >>> >>> If you could debug that it would be great. >>> >>> --HPS >>> >> ok, so yes I can probably try debugging the driver for the FT232BL chip, >> but the support for my device's manufacturer is very limited, so it >> might not be optimal to try doing debugging with that. Plus although I >> do programming all day (statistical data analysis), I've never done >> coding at the kernel level or driver programming, so I will need to get >> familiar with it first. >> > > Don't worry about your coding skills. If you can add the code that makes it > working, I will fix the rest for you. > > >> Would something like >> http://www.eurodesign.bg/eudesignbg/USB_RS232.html be the ideal tool for >> debugging? >> > > I don't know .... > > --HPS > Hi, so I compared the control commands sent by uftdi to the ones sent by ftdio_sio (linux kernel module) and I tried different hacks to finally realize that the problem was that FreeBSD was not sending the right baud rate to the device. FreeBSD uses c_ospeed (in termios struct) to get the baud rate while Linux uses c_cflag. So I removed the baud rate from c_cflag in my code and I am now using cfsetispeed and cfsetospeed. I though the termios structure and flags were Posix but it looks like it's not :S. So to conclude, it looks like uftdi is working fine :) Thanks for the support!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ABEF2A6.6010801>