lkml.org 
[lkml]   [2009]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: Is anyone maintaining (or even using) usbtmc?
    i've asked also some of your questions two month ago.

    i'm a tmc driver user only. i use it to develop my firmware for a
    cypress fx2 based tmc device.

    i've made some bugreporting to greg and to the mailinglist (now i'm not
    sure anymore if all my mails arrived on the mailinglist. the gmame
    archive does not list all mails. the other archives are even worse).

    since then two ore tree small patches are sent to the mailinglist. but
    none seemed to adress my bugs (one patch was about a memory leak)

    > If the answer is no (as I suspect it is), then I might give fixing it
    > a shot the week after next, when I'll be camping out in Virginia with
    > this thing for awhile. In that case, I have another question:

    do it. greg is the maintainer of the whole usb stuff and is working
    really hard. so i understand that he only has little time on "our"
    usbtmc bugs. in my opionion it's good when you do it to help greg with
    it. he still is the maintainer and has to sign of your patches.

    the other thing is, that i belive, please correct me, that greg don't
    has an usbtmc device to test with. for me it seems that there is lack
    of testing in the usbtmc driver. thats why i assume this.

    as i wrote in my older mails, i've never worked on the kernel source. i
    can do some testing with different devices (in our lab we have serveral
    tmc devices).

    > Is anyone using usbtmc, or, more specifically, does anyone care about
    > backward compatibility?

    it doesn't look like that. i don't care if the interface changes. i'm
    still working with the old agilent one until the mainline one works.

    > Finally, I see no way to read the USB488 status byte or detect a
    > status interrupt.
    >
    > >
    > >> Is anyone using usbtmc, or, more specifically, does anyone care
    > >> about backward compatibility?
    > >
    > > What do you want to change in the driver interface?
    >
    > The main compatibility-breaking change is that I'd like to see
    > close/reopen go through the whole resynchronization procedure so that
    > the device starts in a sane state. Currently I restore sanity by
    > doing a bunch of reads and ignoring ETIMEDOUT.
    > If not, then I'll be less careful to preserve the interface, even
    > though I'm not really sure that there's much of interest to preserve.

    to read the USB488 status byte i guess that there is still an ioctl
    function for it (was there in the opensource agilent driver) but you
    can get the status byte with a normal "*STB?" query.

    the lack of interrupt status reporting is an important one. so you have
    to quess, or do stupid polling, until your device is finished working.
    the normal way is to set "opc?" and do something else until the
    response from the interrupt endpoint arrives.

    christoph

    \
     
     \ /
      Last update: 2009-08-06 15:27    [W:6.835 / U:0.072 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site