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