Writing a Comedi driver

[Simon Pickering]

Hi,

I've just written a Comedi driver for a PCI high voltage DAC card and
wanted to ask a driver-related question and also make a comment or two
about the website (as someone who has just come to Comedi and used the
docs to get going).

First of all is the question of whether I can switch my card's
analogue outputs on at some point after the kernel module is loaded
(e.g. via some Comedilib command or ideally when the relevant device
file is opened)? I currently set the card outputs to 0V when the
driver is initialised, but as the card in question outputs either 150
or 500V (depending on the exact model), I'd prefer to have it
completely off until it's needed.

I also have a couple of comments about the website - the first one is
that the wiki link on this page is broken (http://comedi.org/
documentation.html) and emails to webm...@comedi.org get bounced.
Secondly, I see that the HTML docs on the site are out of date -
certainly the driver writing section doesn't seem to have current
information on some of the structures. I also noted that the parameter
list for e.g. comedi_to_phys() is different in the "3.2. Converting
samples to voltages" section (http://comedi.org/doc/x403.html) vs. the
stand alone page describing the function (http://comedi.org/doc/
r5619.html).

I wonder if a warning that the HTML docs are out of date would be
worth adding to the site (though other than the above points I'm not
sure how out of date, so perhaps it's just a case of correcting some
minor things as it's certainly nice to have the well written and
explained documentation available)? Certainly a pointer to the
Hardware_Driver.HOWTO in the git repo would be useful for driver
writers IMO.

Thanks,


Simon

[Ian Abbott]

On 2012/04/25 12:20 PM, Simon Pickering wrote:
> I've just written a Comedi driver for a PCI high voltage DAC card and
> wanted to ask a driver-related question and also make a comment or two
> about the website (as someone who has just come to Comedi and used the
> docs to get going).

Well done!

> First of all is the question of whether I can switch my card's
> analogue outputs on at some point after the kernel module is loaded
> (e.g. via some Comedilib command or ideally when the relevant device
> file is opened)? I currently set the card outputs to 0V when the
> driver is initialised, but as the card in question outputs either 150
> or 500V (depending on the exact model), I'd prefer to have it
> completely off until it's needed.

There are optional 'open' and 'close' hooks in 'struct
comedi_device_struct' that the driver can set. You could use those to
turn the outputs on and off.

> I also have a couple of comments about the website - the first one is
> that the wiki link on this page is broken (http://comedi.org/
> documentation.html) and emails to webm...@comedi.org get bounced.

I think the wiki contents got lost during a server rebuild. I don't
know if there's a backup anywhere. I suppose David Schleef is still
technically the webmaster, although he's not directly involved in Comedi
any more. I guess it's better to bounce the messages than tip them into
a bitbucket. Comments on the website can be made on the mailing list.

> Secondly, I see that the HTML docs on the site are out of date -
> certainly the driver writing section doesn't seem to have current
> information on some of the structures. I also noted that the parameter
> list for e.g. comedi_to_phys() is different in the "3.2. Converting
> samples to voltages" section (http://comedi.org/doc/x403.html) vs. the
> stand alone page describing the function (http://comedi.org/doc/
> r5619.html).

The HTML docs will be updated when we release an official version of
comedilib. That's "real soon now" (probably about a week to tie up any
loose ends in the packaging and documentation).

> I wonder if a warning that the HTML docs are out of date would be
> worth adding to the site (though other than the above points I'm not
> sure how out of date, so perhaps it's just a case of correcting some
> minor things as it's certainly nice to have the well written and
> explained documentation available)? Certainly a pointer to the
> Hardware_Driver.HOWTO in the git repo would be useful for driver
> writers IMO.

Adding some version information to the online docs and comedilib manual
would be a good start! We can add some comment about the age of the
comedilib manual, but I'll leave that until after upcoming release of
comedilib.

I think there might have been some info in the wiki about driver
writing, but that got lost.

We can add a link to the Hardware_Driver.HOWTO (such as it is, it's a
bit basic!) to the Documentation page.

--
-=( Ian Abbott @ MEV Ltd. E-mail: <abb...@mev.co.uk> )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-

[Simon Pickering]

> > First of all is the question of whether I can switch my card's
> > analogue outputs on at some point after the kernel module is loaded
> > (e.g. via some Comedilib command or ideally when the relevant device
> > file is opened)? I currently set the card outputs to 0V when the
> > driver is initialised, but as the card in question outputs either 150
> > or 500V (depending on the exact model), I'd prefer to have it
> > completely off until it's needed.
>
> There are optional 'open' and 'close' hooks in 'struct
> comedi_device_struct' that the driver can set.  You could use those to
> turn the outputs on and off.

Great, I remember seeing those now and wondering what they were used
for. Thanks.

> > I also have a couple of comments about the website - the first one is
> > that the wiki link on this page is broken (http://comedi.org/

> > documentation.html) and emails to webmas...@comedi.org get bounced.

>
> I think the wiki contents got lost during a server rebuild.  I don't
> know if there's a backup anywhere.  I suppose David Schleef is still
> technically the webmaster, although he's not directly involved in Comedi
> any more.  I guess it's better to bounce the messages than tip them into
> a bitbucket.  Comments on the website can be made on the mailing list.

I didn't really want to send my first email consisting solely of me
saying there are things wrong with the site, so I had to write my
driver first! ;)

> > Secondly, I see that the HTML docs on the site are out of date -
> > certainly the driver writing section doesn't seem to have current
> > information on some of the structures. I also noted that the parameter
> > list for e.g. comedi_to_phys() is different in the "3.2. Converting
> > samples to voltages" section (http://comedi.org/doc/x403.html) vs. the
> > stand alone page describing the function (http://comedi.org/doc/
> > r5619.html).
>
> The HTML docs will be updated when we release an official version of
> comedilib.  That's "real soon now" (probably about a week to tie up any
> loose ends in the packaging and documentation).

Ok that's fine, I just wanted to make sure people were aware.

> > I wonder if a warning that the HTML docs are out of date would be
> > worth adding to the site (though other than the above points I'm not
> > sure how out of date, so perhaps it's just a case of correcting some
> > minor things as it's certainly nice to have the well written and
> > explained documentation available)? Certainly a pointer to the
> > Hardware_Driver.HOWTO in the git repo would be useful for driver
> > writers IMO.
>
> Adding some version information to the online docs and comedilib manual
> would be a good start!  We can add some comment about the age of the
> comedilib manual, but I'll leave that until after upcoming release of
> comedilib.
>
> I think there might have been some info in the wiki about driver
> writing, but that got lost.
>
> We can add a link to the Hardware_Driver.HOWTO (such as it is, it's a
> bit basic!) to the Documentation page.

If I can find some time I'll try to expand some of the missing parts
in the driver explanation section (the bits I had to dig around for
and that might therefore be worth adding in).

I'll also clean my code up once I've implemented the open/close
callback functionality and submit it for comments.

Cheers,


Simon

[Simon Pickering]

Hi,

I've finally got around to implementing the open and close callback functionality. The driver seems to work fine and so I've attached the code to this email for comments.

What form is preferred for a submission for inclusion in the codebase - a full diff against the git repo's head (driver source, plus comedidev.h, Makefile.am and Kbuild modifications)?

Thanks,

Simon

[Ian Abbott]

Hi Simon,

Is it possible to match the PCI subdevice ID on these boards? You are
currently matching only the generic vendor ID and device ID for a PLX
PCI 9050 or 9052, which is not acceptable for a PCI device table as it
is too generic and will match unrelated devices.

There is not much excuse for the manufacturer not to make the PCI
information unique as PLX will give out device IDs or subdevice IDs for
free as long as their chips are used in the design.

Also, I'd recommend targetting the Linux "staging" comedi codebase in
the Linux kernel sources instead of (or in addition to) the comedi.org
codebase.

Best regards,
Ian.

[Simon Pickering]

Is it possible to match the PCI subdevice ID on these boards? You are currently matching only the generic vendor ID and device ID for a PLX PCI 9050 or 9052, which is not acceptable for a PCI device table as it is too generic and will match unrelated devices.

I'll have a look at the docs (and the card I have) and see what the subdevice ID(s) are.

There is not much excuse for the manufacturer not to make the PCI information unique as PLX will give out device IDs or subdevice IDs for free as long as their chips are used in the design.

I only have the one card, but will contact the manufacturer to ask whether each card has a unique subdevice ID. 

Also, I'd recommend targetting the Linux "staging" comedi codebase in the Linux kernel sources instead of (or in addition to) the comedi.org codebase.

Ok great,

Thanks,

Simon

 

[Ian Abbott]

On 11/12/12 11:50, Simon Pickering wrote:
>
> Is it possible to match the PCI subdevice ID on these boards? You
> are currently matching only the generic vendor ID and device ID for
> a PLX PCI 9050 or 9052, which is not acceptable for a PCI device
> table as it is too generic and will match unrelated devices.
>
>
> I'll have a look at the docs (and the card I have) and see what the
> subdevice ID(s) are.
>
> There is not much excuse for the manufacturer not to make the PCI
> information unique as PLX will give out device IDs or subdevice IDs
> for free as long as their chips are used in the design.
>
>
> I only have the one card, but will contact the manufacturer to ask
> whether each card has a unique subdevice ID.

If you can get hold of the Windows drivers, the information may be in an
INF file.

[Mariett Aleuzenev Urbina Candales]

hi somebody can help me?... i need to know if the 

Low-Cost 16-Bit, 200 kS/s, 16 Analog Input Multifunction DAQ... can use comedi..... because i can't find this card in the list in comedi page... please help me

[Ian Abbott]

Note for the list: Mariett is referring to the NI PCI-6010 in the above.

It is not currently supported and I don't think anyone is working on
supporting extra NI cards at the moment. Frank (fmhess) was Comedi's
main NI driver guy but hasn't been working on Comedi very much recently.


Technical comment:

I think the PCI-6010 register layout is similar to the supported
M-series cards (even though it is a B-series card). This thread
suggests it may be similar to the PCI-622x cards:

http://forums.ni.com/t5/Driver-Development-Kit-DDK/PCI-6010-register-map-vxWorks-driver/td-p/637776

But I don't know exactly which bits of the PCI-622x cards also apply to
the PCI-6010. In any case, someone who knows what they are doing and
who has access to the hardware would be needed to add support for this
card to the Comedi ni_pcimio driver.