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
