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
