Re: extra board specific functions

Hi,

On 04/09/07, Ian Abbott <abbotti_at_mev.co.uk> wrote:
> On 24/08/2007 11:14, Gergely Imreh wrote:
> > Thanks for the advice, they are very useful....
> >
> > Nevertheless, I keep running into problems, probably because I need to
> > know more about the whole working of Comedi.
> >
> > For example: if I write my s->do_cmd, if it returns 0, than my program
> > can call it only once, after that whenever I call it, Comedi just
> > bounces back with -1, not even calling the cmdtest, or anything else.
> > If I define return 1; (or anything >0), than it can run it multiple
> > times....
>
> s->do_cmd should return 0 unless something drastic happens, such as
> failing to allocate memory or something, in which case it should return
> a negative error value.  All the command compatibility checking is done
> in a previous call to s->do_cmdtest.

That's what i thought too, so my do_cmd returns 0 in general, and the
do_cmdtest does the first testing.

>
> > What am I missing? Is the driver supposed to have anything special in
> > the do_cmd, and maybe comedi is waiting for it?
> >
> > I use these command sources (and made the cmdtest to allow these)
> >   cmd.start_src      = TRIG_NOW;
> >   cmd.scan_begin_src = TRIG_INT;
> >   cmd.convert_src    = TRIG_NOW;
> >   cmd.scan_end_src   = TRIG_COUNT;
> >   cmd.stop_src       = TRIG_NONE;
>
> I'm guessing that you are trying to start a new command before the old
> one is finished.  If cmd.stop_src is TRIG_NONE it will never finish by
> itself.  Call comedi_cancel to stop it.

I think that's true, when I check the human readable form of the error
code, it's "Success" for the 1st cmd call, after that "Device or
resource busy".

Any suggestion how I should do, if I only want to use the cmd not
necessary to output values to the DAC channels, but to change the
output mode (immediate or triggered update)?

I thought, making a simple cmd, and there assigning my own function to
the s->async->inttrig, then returning from the cmd, would be enough.
But obviously not.
If I assign s->async->inttrig = my_inttrig; then inside the cmd I can
test it by calling s->async->inttrig and that will call my function,
but when I actually try to trigger from the external program, after I
called the cmd, it will say "Bad address" for trigger error.

Any suggestion what should be the proper way, calling the cmd only to
set up the INTTRIG, and then let it go, so I can use the trigger
afterwards?

I don't think it should be too difficult, once I figure out how to
write one driver properly, everything will be much simpler, and many
things feel already more logical than in the beginning when I started
to look at it, but there are still some missing spots.... It's very
good stuff, though, all the comedi things....

> In general, you can do kernel-level debugging by inserting a few printk
> calls in the code.

Yes, I do that all the time, my driver code is full of debugging outputs...
:)

Cheers,
     Greg