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,
> 
> -Stefan
> 
> 
> 
> 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
> >> 
> >> 
> > 
> 

-- 
Alexis.

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to