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. 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 _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
