Re: [Xenomai-core] analogy - experimental branch

[Stefan Schaal <sschaal@domain.hid>]

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?

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