Hi, On Wed, Sep 8, 2010 at 4:30 PM, Stefan Schaal <ssch...@usc.edu> 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@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 >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Alexis. >>>>>> >>>>> >>>>> -- >>>>> Alexis. >>>> >>>> >>>> _______________________________________________ >>>> 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
