Stefan Schaal wrote:
> Hi Alexis,
> thanks a lot for the explanations. One item I am confused about is
> that you write that TRIG_TIMER is not suitable for DIO, but in
> cmd_write.c in your sample code, it is used for the analog write
> without problems. Wouldn't one be able to just use the same clock
> source for DIO as in analogue I/O?
The analog output subdevice has its own sampling source. That is why,
according to the command API logic, TRIG_TIMER is appropriate. It
indicates that the scans are triggered by a periodic timer delivered
by the analog output subsystem.
> Best wishes,
> On Jul 12, 2010, at 15:29, Alexis Berlemont wrote:
> > Hi,
> > Stefan Schaal wrote:
> >> Hi Alexis,
> >> I guess I slowly understand that my clocking signal connected to
> >> scan_begin_arg has to come from an external DIO input, if
> >> scan_bigin_src = TRIG_EXT, and that the insn instruction is still
> >> needed to trigger the entire acquisition.
> > Yes. The trigger instruction is needed so as to start the whole
> > acquisition (which is composed of many scans). A periodic external
> > signal is needed so as to trigger each scan.
> >> Alternatively, would it be possible to use the internal clocking signals
> >> like
> >> scan_bigin_src = TRIG_FOLLOW
> >> or
> >> scan_bigin_src = TRIG_TIMER
> > I think you are right. If the sampling clock comes from another
> > subdevice, TRIG_EXT may not be the most appropriate constant. However,
> > the original comedi driver only expects TRIG_EXT even if... the
> > sampling signal is not external.
> > TRIG_TIMER does not seem suitable because it assumes an independant
> > sampling clock is available.
> > And TRIG_FOLLOW may be the most appropriate one. We should modify the
> > driver so that TRIG_FOLLOW is used if the analog sampling clock is
> > chosen.
> >> if I try any of these sources, I get an error -22, and dmesg reports:
> >> [195882.321300] Analogy: a4l_check_cmddesc: scan_begin_src, trigger
> >> unsupported
> > For me, the command interface is an empty shell because the various
> > parameters (start_src, scan_begin_src, ...) and the values (TRIG_*)
> > are imposed. And, on the other side, the driver is fully in charge of
> > the command structure as it is. So, the comedi command imposes a
> > communication method but does not ease the driver's task of managing
> > it (errors checking, translation, etc.)
> > And, in our case: DIO, we may conclude that this imposed API does not
> > fit well: in scan_begin_arg, we have to pass an index which is
> > supposed to correspond to some sampling clock (which is specific to a
> > board). Then, we use a generic interface with board-specific
> > arguments.
> > So, to sum up, I understand your point: the way we control the driver
> > may not always be the most appropriate one. But, we inherited from
> > comedi both the interface and the drivers.
> > On my side, I am working on trying to implement (as a background task)
> > a generic interface a little bit more based on discovery (query /
> > enum) that would render the command interface obsolete. Unfortunately,
> > I have nothing interesting to show yet.
> >> Best wishes,
> >> -STefan
Xenomai-core mailing list