Stefan Schaal wrote: > Hi Alexis, > > maybe it is more useful to mention what I actually want to achieve with DIO > on my NI6259. My DIO communication involves a series of interactions with > another board to collect sensory data from a robot, and to send out commands > to this board. For instance, to read one of the sensors, a sequence of DIO > values need to be written to tell the board to send the data. I programmed > this initially with synchronous instructions using a4l_sync_dio(), but this > turns out to be too slow. Thus, the hope is to use commands, i.e., fill the > FIFO with the sequence of values which I need to execute, and then use > asynchronous DIO to obtain much higher speed of communicating the values in > the FIFO. > > Thus, what I essentially try to do is to put about 10-20 scans in the > FIFO, and then write the FIFO as fast as possible to my NI6259 DIO subdevice. > > Would you have any ideas how to do this fast writing of the scans in the FIFO > with the current analogy functionality? > Right now, I don't know. I think your idea of using DIO commands may be suitable (I don't know your timing constraints). So what not proceeding ?
> Thanks a lot! > > -Stefan > > > On Jul 12, 2010, at 22:51, 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? > > > > 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 > > Xenomai-core@gna.org > > https://mail.gna.org/listinfo/xenomai-core > -- Alexis. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
