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 >> >> > _______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core