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
