Re: [Xenomai-core] analogy - experimental branch

[Stefan Schaal <sschaal@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 159 bytes --]

Hi Alexis,

  attached a document I found with NI. Look for the DIO_COMMAND section (at the end of the document. Is this useful?

Best wishes,

-Stefan

[-- Attachment #2: mseries_registermap.doc --]
[-- Type: application/msword, Size: 2551296 bytes --]

[-- Attachment #3: Type: text/plain, Size: 14756 bytes --]


On Sep 8, 2010, at 23:51, Alexis Berlemont wrote:

> Hi,
> 
> On Wed, Sep 8, 2010 at 4:30 PM, Stefan Schaal <sschaal@domain.hid> wrote:
>> Hi Alexis,
>> 
>>   sorry for my late reply -- I was traveling.
>> 
>> Essentially, in my DIO communication, I need to switch some DIO channels from READ to WRITE after several scans, and than back. This is why the stop argument would be very useful.
>> 
>> Also, currently in the cmd_bits test program, one gets a lot messages from dmesg:
>> 
>> [1325379.753432] Analogy: MITE: DMA underrun
>> 
>> which comes, I guess, from not continuously filling the FIFO buffer with data.
>> 
>> I will try to look through comedi and the NI documentation what register might have the counting information.
> 
> The needed documentation is the register level programing manual for M
> series. The registers related with asynchronous DIO acquisition are
> not defined in the DAQ documentation.
> 
>> 
>> Best wishes,
>> 
>> -Stefan
>> 
>> 
> 
> Alexis.
> 
>> On Sep 4, 2010, at 14:45, Alexis Berlemont wrote:
>> 
>>> Hi,
>>> 
>>> Stefan Schaal wrote:
>>>> Hi Alexis,
>>>> 
>>>> we are making great progress with our work. One issue that came up is whether it would be possible to add
>>>> 
>>>>   .stop_src = TRIG_COUNT,
>>>>   .stop_arg = n,
>>>> 
>>>> in the command structure, i.e., that the command terminates after n scans. Currently, when I try this, dmesg tells me that this method is not supported.
>>>> 
>>> I don't have the documentation of the CDIO registers; so, I dont' know
>>> how to tell the subdevice to stop after having sent a specified amount
>>> of data.
>>> 
>>> However, analogy stops an acquisition when the stop_arg of the command
>>> structure has been reached. We would be able to cancel the acquisition
>>> after having sent _at_ _least_ the specified amount but we would not
>>> be able to accurately send the specified amount of data.
>>> 
>>> I think we should firstly get the proper documentation. I will try to
>>> have a look at the open source code delivered by NI.
>>> 
>>>> Best wishes,
>>>> 
>>>> -Stefan
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Aug 23, 2010, at 23:49, Stefan Schaal wrote:
>>>> 
>>>>> Hi Alexis,
>>>>> 
>>>>> amazing progress!! And it works! I just ran my test program on our NI6259 board and got perfect performance. I quickly tested 5MHz  DIO rate, and it appeared to work fine according to the square waves on the oscilloscope.
>>>>> 
>>>>> I will go back to developing our DAQ interface, and report back to the Xenomai list about performance.
>>>>> 
>>>>> Thanks so much!!!!
>>>>> 
>>>>> Best wishes,
>>>>> 
>>>>> -Stefan
>>>>> 
>>>>> 
>>>>> On Aug 23, 2010, at 16:09, Alexis Berlemont wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Stefan Schaal wrote:
>>>>>>> Hi Alexis,
>>>>>>> 
>>>>>>> as usually, we are more than grateful that you are willing to spend time on this issue. Here are answers to your questions:
>>>>>>> 
>>>>>>> 1) I tried CR_INVERT -- no success
>>>>>>> 2) I tried very slow frequencies like 10Hz in the counter clock (which is nicely visualized on my oscilloscope) -- no success
>>>>>>> 3) I tried to send a 0 with cmd_bits -- and interestingly, this ALSO takes my DIO line high (sorry, I thought I had tested this before). This would indicate that we do not access the FIFO at all?
>>>>>>> 4) I have my own test program to send alternating 0xffffffff and 0x0 values to the devices to generate a square wave on the oscilloscope. I cannot see anything of the square wave executed.
>>>>>>> 
>>>>>> 
>>>>>> At last, it comes!!!
>>>>>> 
>>>>>> Thanks to your test program and your help, I think I have fixed this
>>>>>> bug. Could you clone my git repository (branch analogy), and give it a
>>>>>> try with your own test program.
>>>>>> 
>>>>>> There was a bug in the mite configuration which explained why the
>>>>>> wrong data were sent to the DIO subdevice. That was also the reason
>>>>>> why no interrupt came from the mite.
>>>>>> 
>>>>>>> Best wishes,
>>>>>>> 
>>>>>>> -Stefan
>>>>>>> 
>>>>>>> 
>>>>>>> On Jul 19, 2010, at 15:01, Alexis Berlemont wrote:
>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Sorry for answering late.
>>>>>>>> 
>>>>>>>> Stefan Schaal wrote:
>>>>>>>>> Hi Alexis,
>>>>>>>>> 
>>>>>>>>> I managed to port some of the Comedi examples to Analogy. In particular, I could configure one of my counter subdevices to become a high frequency clock, following the gpct_pulse_generator.c example. I routed the output of the clock to my PFI0 pin, and could visualize the signal on an oscilloscope. Thus, I know have the clock I need to trigger CMD-based DIO, as you suggested. (I will post some sample code of this in the near future after all is cleaned up).
>>>>>>>>> 
>>>>>>>>> Next, I went back to cmd_bits.c and try to make it work on my NI6259 board. For scan_begin_src=TRIG_EXT   I need to choose scan_begin_arg = 28 (which is kCDO_Update_Source_SelectG0_Out in the NI documentation, and NI_CDIO_SCAN_BEGIN_SRC_G0_OUT in the comedi.h file).
>>>>>>>>> 
>>>>>>>>> When running cmd_bits.c in this way and monitoring the DO channels on an oscilloscope, the DO switches to HIGH when the acquisition is triggered (i.e., the value of the first element in the FIFO), but the FIFO is not processed any further, i.e., not emptied. If I DO NOT run the counter-clock above, the DO does not even switch to HIGH. I also checked whether 28 is the right value for scan_begin_arg by trying a wide range of values, but only for scan_begin_arg = 28 I get the DO bit switched to HIGH at the beginning of the acquisition.
>>>>>>>>> 
>>>>>>>>> In Comedi, the cmd.flags is set to CMDF_WRITE for such externally triggered acquisitions, which I tried, but it did not help.
>>>>>>>>> 
>>>>>>>>> Thus, it appears that I still have a problem in processing the FIFO, despite it appears that all other things are now correctly connected (Comedi has an example do_waveform.c, which is pretty much what I try to use for testing in my own code).
>>>>>>>>> 
>>>>>>>>> Would you have any thoughts on what might go wrong? It looks like we are just a tiny bit away from succeeding with cmd_bits.c on my board.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> I had time to have a look at your problem. Unfortunately, I do not
>>>>>>>> have any solution. I just have some questions you may find stupid:
>>>>>>>> 
>>>>>>>> - Did you try to invert the sample clock polarity by setting the flag
>>>>>>>> CR_INVERT in the command field scan_begin_arg?
>>>>>>>> - Which frequencies did you generate with the counter subdevice? Even
>>>>>>>> the lowest one did nothing (Something like 10Hz)?
>>>>>>>> - Did you try to send 0 with cmd_bits ? Just to check that the DO stay
>>>>>>>> to LOW, which would mean that the values (or at least the first one)
>>>>>>>> are properly loaded into the device.
>>>>>>>> - So far, cmd_bits always sends the same value (the one you passed as
>>>>>>>> argument); we should modify it so that the complement value is
>>>>>>>> written every two samples. That would allow us to physically check
>>>>>>>> how many samples are "played" by the DO.
>>>>>>>> 
>>>>>>>>> Best wishes,
>>>>>>>>> 
>>>>>>>>> -Stefan
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Jul 14, 2010, at 17:46, Stefan Schaal wrote:
>>>>>>>>> 
>>>>>>>>>> Hi Alexis,
>>>>>>>>>> 
>>>>>>>>>> in the Comedi examples (http://www.comedi.org/download/comedilib-0.8.1.tar.gz, the do_waveform.c example), they suggest to use a general purpose counter as clocking input to a cmd-based DIO acquisition. This seems to be the signal "kCDO_Update_Source_SelectG0_Out            = 28" from the enum you found in the NI documentation.
>>>>>>>>>> 
>>>>>>>>>> For this purpose, the counter needs to be configured and triggered. Does Analogy already have the functionality to do such operations? The Comedi libraries have an example for this, too, in gpct_pulse_generator.c, just that this example uses a variety of function calls that I cannot directly map to the current Analogy functionality.
>>>>>>>>>> 
>>>>>>>>>> Or, do you happen to know whether there is another, easier to access, clock source?
>>>>>>>>>> 
>>>>>>>>>> Best wishes,
>>>>>>>>>> 
>>>>>>>>>> -Stefan
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Jul 14, 2010, at 14:03, Alexis Berlemont wrote:
>>>>>>>>>> 
>>>>>>>>>>> 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.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Xenomai-core mailing list
>>>>>>>>>> Xenomai-core@domain.hid
>>>>>>>>>> https://mail.gna.org/listinfo/xenomai-core
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Alexis.
>>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Alexis.
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Xenomai-core mailing list
>>>>> Xenomai-core@domain.hid
>>>>> https://mail.gna.org/listinfo/xenomai-core
>>>> 
>>> 
>>> --
>>> Alexis.
>> 
>>