Re: [Xenomai-core] analogy - experimental branch

[Alexis Berlemont <alexis.berlemont@domain.hid>]

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@domain.hid
> > https://mail.gna.org/listinfo/xenomai-core
> 

-- 
Alexis.