Re: [Xenomai-core] analogy - experimental branch
Hi, On Wed, Sep 8, 2010 at 4:30 PM, Stefan Schaal ssch...@usc.edu wrote: Hi Alexis, sorry for my late reply -- I was traveling. Essentially, in my DIO communication, I need to switch some DIO channels from READ to WRITE after several scans, and than back. This is why the stop argument would be very useful. Also, currently in the cmd_bits test program, one gets a lot messages from dmesg: [1325379.753432] Analogy: MITE: DMA underrun which comes, I guess, from not continuously filling the FIFO buffer with data. I will try to look through comedi and the NI documentation what register might have the counting information. The needed documentation is the register level programing manual for M series. The registers related with asynchronous DIO acquisition are not defined in the DAQ documentation. Best wishes, -Stefan Alexis. On Sep 4, 2010, at 14:45, Alexis Berlemont wrote: 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 0x 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
Re: [Xenomai-core] analogy - experimental branch
Hi Alexis, sorry for my late reply -- I was traveling. Essentially, in my DIO communication, I need to switch some DIO channels from READ to WRITE after several scans, and than back. This is why the stop argument would be very useful. Also, currently in the cmd_bits test program, one gets a lot messages from dmesg: [1325379.753432] Analogy: MITE: DMA underrun which comes, I guess, from not continuously filling the FIFO buffer with data. I will try to look through comedi and the NI documentation what register might have the counting information. Best wishes, -Stefan On Sep 4, 2010, at 14:45, Alexis Berlemont wrote: 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 0x 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
Re: [Xenomai-core] analogy - experimental branch
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 0x 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
Re: [Xenomai-core] analogy - experimental branch
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 0x 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
Re: [Xenomai-core] analogy - experimental branch
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 0x 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
Re: [Xenomai-core] analogy - experimental branch
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 0x 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
Re: [Xenomai-core] analogy - experimental branch
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:
Re: [Xenomai-core] analogy - experimental branch
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 0x 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
Re: [Xenomai-core] analogy - experimental branch
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. 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
Re: [Xenomai-core] analogy - experimental branch
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? The analog output subdevice has its own sampling source. That is why, according to the command API logic, TRIG_TIMER is appropriate. It indicates that the scans are triggered by a periodic timer delivered by the analog output subsystem. 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 -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] analogy - experimental branch
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
Re: [Xenomai-core] analogy - experimental branch
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
Re: [Xenomai-core] analogy - experimental branch
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? 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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] analogy - experimental branch
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.
Alternatively, would it be possible to use the internal clocking signals like
scan_bigin_src = TRIG_FOLLOW
or
scan_bigin_src = TRIG_TIMER
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
Best wishes,
-STefan
On Jul 9, 2010, at 17:10, Stefan Schaal wrote:
Hi Alexis,
thanks a lot for the clarification. Thus, scan_begin_arg is set to the
digital line that I would like to use as a trigger. The triggering itself has
to happen by flipping the bit on this specific digital line, e.g., using
a4l_sync_dio() on this specific line? I assume that I do not need to re-wire
anything on my board.
In your cmd_bits.c code, you use the a4l_insn_t insn structure below for
triggering, which is what I have to replace with a4l_sync_dio(), I guess?
Best wishes,
-Stefan
On Jul 9, 2010, at 15:17, Alexis Berlemont wrote:
Stefan Schaal wrote:
Hi Alexis,
I conceptually understand what you are telling us, but I am bit confused
how to implement your advice:
So, Stefan, here is a quick solution:
if you have access to your board you can choose one of these signals
(in which a regular pulse is occuring) and you can modify accordingly
the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c.
The data structures in question are:
/* The command to send by default */
a4l_cmd_t cmd = {
.idx_subd = -1,
.flags = 0,
.start_src = TRIG_INT,
.start_arg = 0,
.scan_begin_src = TRIG_EXT,
.scan_begin_arg = 0, /* in ns */
.convert_src = TRIG_NOW,
.convert_arg = 0, /* in ns */
.scan_end_src = TRIG_COUNT,
.scan_end_arg = 4,
.stop_src = TRIG_NONE,
.stop_arg = 0,
.nb_chan = 4,
.chan_descs = chans,
};
a4l_insn_t insn = {
.type = A4L_INSN_INTTRIG,
.idx_subd = -1,
.data_size = 0,
};
Thus, I assume you mean that
scan_begin_src = TRIG_EXT
should be modified to one of the enum items below? Are all these
timers automatically running, or do they need to be configured, too?
Sorry, I am a bit at a loss how to proceed.
Sorry for the delay.
I was not clear enough. In fact, scan_begin_arg should be
modified. scan_begin_src indicates the type of trigger and
scan_begin_arg gives an associated argument. In our case, it is the
signal number. Sorry for the comment (/* in ns */) which is an
inappropriate copy-paste (as a matter of fact, it is the whole command
interface which is unsuitable but that's another topic).
Best wishes,
-Stefan
On Jul 5, 2010, at 15:02, Alexis Berlemont wrote:
Hi,
Alexis Berlemont wrote:
Hi,
Stefan Schaal wrote:
Hi Alexis,
thanks for the feedback. We have 32 bit DIO on subdevice #2, and I am
not sure that there is anything special to be configured. I will check
again. Feel free to log into our machine with the pwd I indicated to you
some time ago. The computer is not used productively.
Sorry for answering late, I was unavailable.
My question was: did you ensure that the digital line were properly
modified after having launched cmd_bits ?
As I said, the digital output system does not consume the data (now I
am sure). I instrumetented the code and I found out that the mite
copied about 8000 bytes from the RAM and filled the digital output
FIFO. Then, the DO FIFO status register keeps on indicating the FIFO
is full. Nothing happens, the digital output system does not retrieve
data from the FIFO.
I tried to find out why and I had a close look at the driver: I
noticed that no sample clock was configured. The driver only proposes
to use an external signal (from the digital system, so AI/AO clocks,
counters, PFI, etc.) as sample clock. Unfortunately, I do not know
which value corresponds to which clock source.
I had a look a the DAQ documentation: unfortunately the M series
digital system is different (the DAQ-STC document is not valid for
this board). I tried to find the M series developer manual but it is
unavailable according to the NI support. I found a document named
mseries_registermap.doc in:
http://digital.ni.com/express.nsf/bycode/exyv4w?opendocument
Unfortunately, it does not tell how to configure the sample clock
source (I know which register I have to fill, but I do not know which
value to put so as to use AI clock, digital counters or PFI...)
So, I am kind of stuck. I will proceed on looking for the missing
pieces of information. Please, if anyone have the info (the mapping
between the CDO_Mode register values and the sample clock source),
do not hesitate to help us.
Argh, I found it. I did not see an item in the url displayed
Re: [Xenomai-core] analogy - experimental branch
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
On Jul 9, 2010, at 17:10, Stefan Schaal wrote:
Hi Alexis,
thanks a lot for the clarification. Thus, scan_begin_arg is set to the
digital line that I would like to use as a trigger. The triggering itself
has to happen by flipping the bit on this specific digital line, e.g.,
using a4l_sync_dio() on this specific line? I assume that I do not need to
re-wire anything on my board.
In your cmd_bits.c code, you use the a4l_insn_t insn structure below for
triggering, which is what I have to replace with a4l_sync_dio(), I guess?
Best wishes,
-Stefan
On Jul 9, 2010, at 15:17, Alexis Berlemont wrote:
Stefan Schaal wrote:
Hi Alexis,
I conceptually understand what you are telling us, but I am bit confused
how to implement your advice:
So, Stefan, here is a quick solution:
if you have access to your board you can choose one of these signals
(in which a regular pulse is occuring) and you can modify accordingly
the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c.
The data structures in question are:
/* The command to send by default */
a4l_cmd_t cmd = {
.idx_subd = -1,
.flags = 0,
.start_src = TRIG_INT,
.start_arg = 0,
.scan_begin_src = TRIG_EXT,
.scan_begin_arg = 0, /* in ns */
.convert_src = TRIG_NOW,
.convert_arg = 0, /* in ns */
.scan_end_src = TRIG_COUNT,
.scan_end_arg = 4,
.stop_src = TRIG_NONE,
.stop_arg = 0,
.nb_chan = 4,
.chan_descs = chans,
};
a4l_insn_t insn = {
.type = A4L_INSN_INTTRIG,
.idx_subd = -1,
.data_size = 0,
};
Thus, I assume you mean that
scan_begin_src = TRIG_EXT
should be modified to one of the enum items below? Are all these
timers automatically running, or do they need to be configured, too?
Sorry, I am a bit at a loss how to proceed.
Sorry for the delay.
I was not clear enough. In fact, scan_begin_arg should be
modified. scan_begin_src indicates the type of trigger and
scan_begin_arg gives an associated argument. In our case, it is the
signal number. Sorry for the comment (/* in ns */) which is an
inappropriate copy-paste (as a matter of fact, it is the whole command
interface which is unsuitable but that's another topic).
Best wishes,
-Stefan
On Jul 5, 2010, at 15:02, Alexis Berlemont wrote:
Hi,
Alexis Berlemont wrote:
Hi,
Stefan Schaal wrote:
Hi Alexis,
thanks for the feedback. We have 32 bit DIO on subdevice #2, and I am
not sure that there is anything special to be configured. I
Re: [Xenomai-core] analogy - experimental branch
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
Re: [Xenomai-core] analogy - experimental branch
Stefan Schaal wrote:
Hi Alexis,
I conceptually understand what you are telling us, but I am bit confused
how to implement your advice:
So, Stefan, here is a quick solution:
if you have access to your board you can choose one of these signals
(in which a regular pulse is occuring) and you can modify accordingly
the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c.
The data structures in question are:
/* The command to send by default */
a4l_cmd_t cmd = {
.idx_subd = -1,
.flags = 0,
.start_src = TRIG_INT,
.start_arg = 0,
.scan_begin_src = TRIG_EXT,
.scan_begin_arg = 0, /* in ns */
.convert_src = TRIG_NOW,
.convert_arg = 0, /* in ns */
.scan_end_src = TRIG_COUNT,
.scan_end_arg = 4,
.stop_src = TRIG_NONE,
.stop_arg = 0,
.nb_chan = 4,
.chan_descs = chans,
};
a4l_insn_t insn = {
.type = A4L_INSN_INTTRIG,
.idx_subd = -1,
.data_size = 0,
};
Thus, I assume you mean that
scan_begin_src = TRIG_EXT
should be modified to one of the enum items below? Are all these
timers automatically running, or do they need to be configured, too?
Sorry, I am a bit at a loss how to proceed.
Sorry for the delay.
I was not clear enough. In fact, scan_begin_arg should be
modified. scan_begin_src indicates the type of trigger and
scan_begin_arg gives an associated argument. In our case, it is the
signal number. Sorry for the comment (/* in ns */) which is an
inappropriate copy-paste (as a matter of fact, it is the whole command
interface which is unsuitable but that's another topic).
Best wishes,
-Stefan
On Jul 5, 2010, at 15:02, Alexis Berlemont wrote:
Hi,
Alexis Berlemont wrote:
Hi,
Stefan Schaal wrote:
Hi Alexis,
thanks for the feedback. We have 32 bit DIO on subdevice #2, and I am
not sure that there is anything special to be configured. I will check
again. Feel free to log into our machine with the pwd I indicated to you
some time ago. The computer is not used productively.
Sorry for answering late, I was unavailable.
My question was: did you ensure that the digital line were properly
modified after having launched cmd_bits ?
As I said, the digital output system does not consume the data (now I
am sure). I instrumetented the code and I found out that the mite
copied about 8000 bytes from the RAM and filled the digital output
FIFO. Then, the DO FIFO status register keeps on indicating the FIFO
is full. Nothing happens, the digital output system does not retrieve
data from the FIFO.
I tried to find out why and I had a close look at the driver: I
noticed that no sample clock was configured. The driver only proposes
to use an external signal (from the digital system, so AI/AO clocks,
counters, PFI, etc.) as sample clock. Unfortunately, I do not know
which value corresponds to which clock source.
I had a look a the DAQ documentation: unfortunately the M series
digital system is different (the DAQ-STC document is not valid for
this board). I tried to find the M series developer manual but it is
unavailable according to the NI support. I found a document named
mseries_registermap.doc in:
http://digital.ni.com/express.nsf/bycode/exyv4w?opendocument
Unfortunately, it does not tell how to configure the sample clock
source (I know which register I have to fill, but I do not know which
value to put so as to use AI clock, digital counters or PFI...)
So, I am kind of stuck. I will proceed on looking for the missing
pieces of information. Please, if anyone have the info (the mapping
between the CDO_Mode register values and the sample clock source),
do not hesitate to help us.
Argh, I found it. I did not see an item in the url displayed above.
Here is an enum found in:
ftp://ftp.ni.com/support/daq/mhddk/examples/nimseries.zip
// Field Accessors (Compile-time selectable)
typedef enum {
kCDO_Update_Source_SelectGround= 0,
kCDO_Update_Source_SelectPFI0 = 1,
kCDO_Update_Source_SelectPFI1 = 2,
kCDO_Update_Source_SelectPFI2 = 3,
kCDO_Update_Source_SelectPFI3 = 4,
kCDO_Update_Source_SelectPFI4 = 5,
kCDO_Update_Source_SelectPFI5 = 6,
kCDO_Update_Source_SelectPFI6 = 7,
kCDO_Update_Source_SelectPFI7 = 8,
kCDO_Update_Source_SelectPFI8 = 9,
kCDO_Update_Source_SelectPFI9 = 10,
kCDO_Update_Source_SelectRTSI0 = 11,
kCDO_Update_Source_SelectRTSI1 = 12,
kCDO_Update_Source_SelectRTSI2 = 13,
kCDO_Update_Source_SelectRTSI3 = 14,
kCDO_Update_Source_SelectRTSI4 = 15,
Re: [Xenomai-core] analogy - experimental branch
Hi Alexis,
thanks a lot for the clarification. Thus, scan_begin_arg is set to the
digital line that I would like to use as a trigger. The triggering itself has
to happen by flipping the bit on this specific digital line, e.g., using
a4l_sync_dio() on this specific line? I assume that I do not need to re-wire
anything on my board.
In your cmd_bits.c code, you use the a4l_insn_t insn structure below for
triggering, which is what I have to replace with a4l_sync_dio(), I guess?
Best wishes,
-Stefan
On Jul 9, 2010, at 15:17, Alexis Berlemont wrote:
Stefan Schaal wrote:
Hi Alexis,
I conceptually understand what you are telling us, but I am bit confused
how to implement your advice:
So, Stefan, here is a quick solution:
if you have access to your board you can choose one of these signals
(in which a regular pulse is occuring) and you can modify accordingly
the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c.
The data structures in question are:
/* The command to send by default */
a4l_cmd_t cmd = {
.idx_subd = -1,
.flags = 0,
.start_src = TRIG_INT,
.start_arg = 0,
.scan_begin_src = TRIG_EXT,
.scan_begin_arg = 0, /* in ns */
.convert_src = TRIG_NOW,
.convert_arg = 0, /* in ns */
.scan_end_src = TRIG_COUNT,
.scan_end_arg = 4,
.stop_src = TRIG_NONE,
.stop_arg = 0,
.nb_chan = 4,
.chan_descs = chans,
};
a4l_insn_t insn = {
.type = A4L_INSN_INTTRIG,
.idx_subd = -1,
.data_size = 0,
};
Thus, I assume you mean that
scan_begin_src = TRIG_EXT
should be modified to one of the enum items below? Are all these
timers automatically running, or do they need to be configured, too?
Sorry, I am a bit at a loss how to proceed.
Sorry for the delay.
I was not clear enough. In fact, scan_begin_arg should be
modified. scan_begin_src indicates the type of trigger and
scan_begin_arg gives an associated argument. In our case, it is the
signal number. Sorry for the comment (/* in ns */) which is an
inappropriate copy-paste (as a matter of fact, it is the whole command
interface which is unsuitable but that's another topic).
Best wishes,
-Stefan
On Jul 5, 2010, at 15:02, Alexis Berlemont wrote:
Hi,
Alexis Berlemont wrote:
Hi,
Stefan Schaal wrote:
Hi Alexis,
thanks for the feedback. We have 32 bit DIO on subdevice #2, and I am not
sure that there is anything special to be configured. I will check again.
Feel free to log into our machine with the pwd I indicated to you some
time ago. The computer is not used productively.
Sorry for answering late, I was unavailable.
My question was: did you ensure that the digital line were properly
modified after having launched cmd_bits ?
As I said, the digital output system does not consume the data (now I
am sure). I instrumetented the code and I found out that the mite
copied about 8000 bytes from the RAM and filled the digital output
FIFO. Then, the DO FIFO status register keeps on indicating the FIFO
is full. Nothing happens, the digital output system does not retrieve
data from the FIFO.
I tried to find out why and I had a close look at the driver: I
noticed that no sample clock was configured. The driver only proposes
to use an external signal (from the digital system, so AI/AO clocks,
counters, PFI, etc.) as sample clock. Unfortunately, I do not know
which value corresponds to which clock source.
I had a look a the DAQ documentation: unfortunately the M series
digital system is different (the DAQ-STC document is not valid for
this board). I tried to find the M series developer manual but it is
unavailable according to the NI support. I found a document named
mseries_registermap.doc in:
http://digital.ni.com/express.nsf/bycode/exyv4w?opendocument
Unfortunately, it does not tell how to configure the sample clock
source (I know which register I have to fill, but I do not know which
value to put so as to use AI clock, digital counters or PFI...)
So, I am kind of stuck. I will proceed on looking for the missing
pieces of information. Please, if anyone have the info (the mapping
between the CDO_Mode register values and the sample clock source),
do not hesitate to help us.
Argh, I found it. I did not see an item in the url displayed above.
Here is an enum found in:
ftp://ftp.ni.com/support/daq/mhddk/examples/nimseries.zip
// Field Accessors (Compile-time selectable)
typedef enum {
kCDO_Update_Source_SelectGround= 0,
kCDO_Update_Source_SelectPFI0 = 1,
kCDO_Update_Source_SelectPFI1 = 2,
kCDO_Update_Source_SelectPFI2 = 3,
kCDO_Update_Source_SelectPFI3 = 4,
kCDO_Update_Source_SelectPFI4 = 5,
kCDO_Update_Source_SelectPFI5 = 6,
kCDO_Update_Source_SelectPFI6 = 7,
Re: [Xenomai-core] analogy - experimental branch
Hi Alexis,
I conceptually understand what you are telling us, but I am bit confused how
to implement your advice:
So, Stefan, here is a quick solution:
if you have access to your board you can choose one of these signals
(in which a regular pulse is occuring) and you can modify accordingly
the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c.
The data structures in question are:
/* The command to send by default */
a4l_cmd_t cmd = {
.idx_subd = -1,
.flags = 0,
.start_src = TRIG_INT,
.start_arg = 0,
.scan_begin_src = TRIG_EXT,
.scan_begin_arg = 0, /* in ns */
.convert_src = TRIG_NOW,
.convert_arg = 0, /* in ns */
.scan_end_src = TRIG_COUNT,
.scan_end_arg = 4,
.stop_src = TRIG_NONE,
.stop_arg = 0,
.nb_chan = 4,
.chan_descs = chans,
};
a4l_insn_t insn = {
.type = A4L_INSN_INTTRIG,
.idx_subd = -1,
.data_size = 0,
};
Thus, I assume you mean that
scan_begin_src = TRIG_EXT
should be modified to one of the enum items below? Are all these timers
automatically running, or do they need to be configured, too? Sorry, I am a bit
at a loss how to proceed.
Best wishes,
-Stefan
On Jul 5, 2010, at 15:02, Alexis Berlemont wrote:
Hi,
Alexis Berlemont wrote:
Hi,
Stefan Schaal wrote:
Hi Alexis,
thanks for the feedback. We have 32 bit DIO on subdevice #2, and I am not
sure that there is anything special to be configured. I will check again.
Feel free to log into our machine with the pwd I indicated to you some time
ago. The computer is not used productively.
Sorry for answering late, I was unavailable.
My question was: did you ensure that the digital line were properly
modified after having launched cmd_bits ?
As I said, the digital output system does not consume the data (now I
am sure). I instrumetented the code and I found out that the mite
copied about 8000 bytes from the RAM and filled the digital output
FIFO. Then, the DO FIFO status register keeps on indicating the FIFO
is full. Nothing happens, the digital output system does not retrieve
data from the FIFO.
I tried to find out why and I had a close look at the driver: I
noticed that no sample clock was configured. The driver only proposes
to use an external signal (from the digital system, so AI/AO clocks,
counters, PFI, etc.) as sample clock. Unfortunately, I do not know
which value corresponds to which clock source.
I had a look a the DAQ documentation: unfortunately the M series
digital system is different (the DAQ-STC document is not valid for
this board). I tried to find the M series developer manual but it is
unavailable according to the NI support. I found a document named
mseries_registermap.doc in:
http://digital.ni.com/express.nsf/bycode/exyv4w?opendocument
Unfortunately, it does not tell how to configure the sample clock
source (I know which register I have to fill, but I do not know which
value to put so as to use AI clock, digital counters or PFI...)
So, I am kind of stuck. I will proceed on looking for the missing
pieces of information. Please, if anyone have the info (the mapping
between the CDO_Mode register values and the sample clock source),
do not hesitate to help us.
Argh, I found it. I did not see an item in the url displayed above.
Here is an enum found in:
ftp://ftp.ni.com/support/daq/mhddk/examples/nimseries.zip
// Field Accessors (Compile-time selectable)
typedef enum {
kCDO_Update_Source_SelectGround= 0,
kCDO_Update_Source_SelectPFI0 = 1,
kCDO_Update_Source_SelectPFI1 = 2,
kCDO_Update_Source_SelectPFI2 = 3,
kCDO_Update_Source_SelectPFI3 = 4,
kCDO_Update_Source_SelectPFI4 = 5,
kCDO_Update_Source_SelectPFI5 = 6,
kCDO_Update_Source_SelectPFI6 = 7,
kCDO_Update_Source_SelectPFI7 = 8,
kCDO_Update_Source_SelectPFI8 = 9,
kCDO_Update_Source_SelectPFI9 = 10,
kCDO_Update_Source_SelectRTSI0 = 11,
kCDO_Update_Source_SelectRTSI1 = 12,
kCDO_Update_Source_SelectRTSI2 = 13,
kCDO_Update_Source_SelectRTSI3 = 14,
kCDO_Update_Source_SelectRTSI4 = 15,
kCDO_Update_Source_SelectRTSI5 = 16,
kCDO_Update_Source_SelectRTSI6 = 17,
kCDO_Update_Source_SelectAI_Start = 18,
kCDO_Update_Source_SelectAI_Convert= 19,
kCDO_Update_Source_SelectPXI_Star_Trigger = 20,
kCDO_Update_Source_SelectPFI10 = 21,
kCDO_Update_Source_SelectPFI11 = 22,
kCDO_Update_Source_SelectPFI12 = 23,
kCDO_Update_Source_SelectPFI13 = 24,
Re: [Xenomai-core] analogy - experimental branch
Hi, Stefan Schaal wrote: Hi Alexis, thanks for the feedback. We have 32 bit DIO on subdevice #2, and I am not sure that there is anything special to be configured. I will check again. Feel free to log into our machine with the pwd I indicated to you some time ago. The computer is not used productively. Sorry for answering late, I was unavailable. My question was: did you ensure that the digital line were properly modified after having launched cmd_bits ? As I said, the digital output system does not consume the data (now I am sure). I instrumetented the code and I found out that the mite copied about 8000 bytes from the RAM and filled the digital output FIFO. Then, the DO FIFO status register keeps on indicating the FIFO is full. Nothing happens, the digital output system does not retrieve data from the FIFO. I tried to find out why and I had a close look at the driver: I noticed that no sample clock was configured. The driver only proposes to use an external signal (from the digital system, so AI/AO clocks, counters, PFI, etc.) as sample clock. Unfortunately, I do not know which value corresponds to which clock source. I had a look a the DAQ documentation: unfortunately the M series digital system is different (the DAQ-STC document is not valid for this board). I tried to find the M series developer manual but it is unavailable according to the NI support. I found a document named mseries_registermap.doc in: http://digital.ni.com/express.nsf/bycode/exyv4w?opendocument Unfortunately, it does not tell how to configure the sample clock source (I know which register I have to fill, but I do not know which value to put so as to use AI clock, digital counters or PFI...) So, I am kind of stuck. I will proceed on looking for the missing pieces of information. Please, if anyone have the info (the mapping between the CDO_Mode register values and the sample clock source), do not hesitate to help us. Best wishes, -Stefan On Jun 30, 2010, at 15:45, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi Alexis, I did a reboot, ran my modified cmd_bits.c again one time. cat /proc/xenomai/irq reports: IRQ CPU0CPU1CPU2CPU3CPU4 CPU5CPU6CPU7 56: 0 0 0 0 0 0 0 0 Analogy device 518: 0 1 1 1 1 1 1 1 [IPI] 521: 626392 618020 618539 620274 617326 625008 622464 626300 [timer] 522: 0 0 0 0 0 0 0 0 [critical sync] 546: 0 0 0 0 0 0 0 0 [virtual] I have not forgotten you. I am still stuck with your bug: The mite transfers the first 8000 bytes and after does nothing; no interrupt is generated by the mite so as to finally awake your application. It seems like the data retrieved by the mite are not consumed by the board. Are you sure the digital output lines correspond to what you configured with cmd_bits ? I think the digital output is misconfigured. I am working on it. -Stefan On Jun 27, 2010, at 3:37, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi Alexis, thanks so much for the new analogy software. Here are some first observations: 1) cmd_bits.c works fine on our NI6250 board 2) however, a slightly modified version hangs -- I appended my cmd_bits.c to this email. All what I added is a for loop around the a4l_async_write() and a4l_snd_insn() commands, i.e., I wanted to trigger a write repeatedly. Look for the sschaal comment in my modified cmd_bits.c . After 32 iterations, cmd_bits hangs, no error messages in dmesg. Interesting, when I change your trigger_threshold variable from 128 to 256, my loop runs for 16 iterations (other changes of the trigger threshold adjust the number of iterations I get in a similar way). Thus, it feels like there is a buffer which does not get reset after a4l_snd_insn() is called -- does this make sense? Could you tell me if the mite triggered an interrupt ? Could you send a dump of cat /proc/xenomai/irq after having made the test program hang ? Many thanks, Best wishes, -Stefan On Jun 24, 2010, at 15:43, Alexis Berlemont wrote: Hi, Alexis Berlemont wrote: Hi Stefan, Stefan Schaal wrote: Hi Alexis, I was just wondering whether the new experimental branch in your git repository is something that can be tried already. No. Not yet. This branch is aimed at temporarily holding the corrections I am trying to do for the cmd_bits issue. It needs quite a lot of work and I have not finished yet.
Re: [Xenomai-core] analogy - experimental branch
Hi,
Alexis Berlemont wrote:
Hi,
Stefan Schaal wrote:
Hi Alexis,
thanks for the feedback. We have 32 bit DIO on subdevice #2, and I am not
sure that there is anything special to be configured. I will check again.
Feel free to log into our machine with the pwd I indicated to you some time
ago. The computer is not used productively.
Sorry for answering late, I was unavailable.
My question was: did you ensure that the digital line were properly
modified after having launched cmd_bits ?
As I said, the digital output system does not consume the data (now I
am sure). I instrumetented the code and I found out that the mite
copied about 8000 bytes from the RAM and filled the digital output
FIFO. Then, the DO FIFO status register keeps on indicating the FIFO
is full. Nothing happens, the digital output system does not retrieve
data from the FIFO.
I tried to find out why and I had a close look at the driver: I
noticed that no sample clock was configured. The driver only proposes
to use an external signal (from the digital system, so AI/AO clocks,
counters, PFI, etc.) as sample clock. Unfortunately, I do not know
which value corresponds to which clock source.
I had a look a the DAQ documentation: unfortunately the M series
digital system is different (the DAQ-STC document is not valid for
this board). I tried to find the M series developer manual but it is
unavailable according to the NI support. I found a document named
mseries_registermap.doc in:
http://digital.ni.com/express.nsf/bycode/exyv4w?opendocument
Unfortunately, it does not tell how to configure the sample clock
source (I know which register I have to fill, but I do not know which
value to put so as to use AI clock, digital counters or PFI...)
So, I am kind of stuck. I will proceed on looking for the missing
pieces of information. Please, if anyone have the info (the mapping
between the CDO_Mode register values and the sample clock source),
do not hesitate to help us.
Argh, I found it. I did not see an item in the url displayed above.
Here is an enum found in:
ftp://ftp.ni.com/support/daq/mhddk/examples/nimseries.zip
// Field Accessors (Compile-time selectable)
typedef enum {
kCDO_Update_Source_SelectGround= 0,
kCDO_Update_Source_SelectPFI0 = 1,
kCDO_Update_Source_SelectPFI1 = 2,
kCDO_Update_Source_SelectPFI2 = 3,
kCDO_Update_Source_SelectPFI3 = 4,
kCDO_Update_Source_SelectPFI4 = 5,
kCDO_Update_Source_SelectPFI5 = 6,
kCDO_Update_Source_SelectPFI6 = 7,
kCDO_Update_Source_SelectPFI7 = 8,
kCDO_Update_Source_SelectPFI8 = 9,
kCDO_Update_Source_SelectPFI9 = 10,
kCDO_Update_Source_SelectRTSI0 = 11,
kCDO_Update_Source_SelectRTSI1 = 12,
kCDO_Update_Source_SelectRTSI2 = 13,
kCDO_Update_Source_SelectRTSI3 = 14,
kCDO_Update_Source_SelectRTSI4 = 15,
kCDO_Update_Source_SelectRTSI5 = 16,
kCDO_Update_Source_SelectRTSI6 = 17,
kCDO_Update_Source_SelectAI_Start = 18,
kCDO_Update_Source_SelectAI_Convert= 19,
kCDO_Update_Source_SelectPXI_Star_Trigger = 20,
kCDO_Update_Source_SelectPFI10 = 21,
kCDO_Update_Source_SelectPFI11 = 22,
kCDO_Update_Source_SelectPFI12 = 23,
kCDO_Update_Source_SelectPFI13 = 24,
kCDO_Update_Source_SelectPFI14 = 25,
kCDO_Update_Source_SelectPFI15 = 26,
kCDO_Update_Source_SelectRTSI7 = 27,
kCDO_Update_Source_SelectG0_Out= 28,
kCDO_Update_Source_SelectG1_Out= 29,
kCDO_Update_Source_SelectAnalog_Trigger= 30,
kCDO_Update_Source_SelectAO_Update = 31,
kCDO_Update_Source_SelectFreq_Out = 32,
kCDO_Update_Source_SelectDIO_Change_Detect_Irq = 33,
} tCDO_Update_Source_Select;
So, Stefan, here is a quick solution:
if you have access to your board you can choose one of these signals
(in which a regular pulse is occuring) and you can modify accordingly
the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c.
Best wishes,
-Stefan
On Jun 30, 2010, at 15:45, Alexis Berlemont wrote:
Hi,
Stefan Schaal wrote:
Hi Alexis,
I did a reboot, ran my modified cmd_bits.c again one time.
cat /proc/xenomai/irq reports:
IRQ CPU0CPU1CPU2CPU3CPU4
CPU5CPU6CPU7
56: 0 0 0 0 0
0 0 0 Analogy device
Re: [Xenomai-core] analogy - experimental branch
Hi, Stefan Schaal wrote: Hi Alexis, I did a reboot, ran my modified cmd_bits.c again one time. cat /proc/xenomai/irq reports: IRQ CPU0CPU1CPU2CPU3CPU4CPU5 CPU6CPU7 56: 0 0 0 0 0 0 0 0 Analogy device 518: 0 1 1 1 1 1 1 1 [IPI] 521: 626392 618020 618539 620274 617326 625008 622464 626300 [timer] 522: 0 0 0 0 0 0 0 0 [critical sync] 546: 0 0 0 0 0 0 0 0 [virtual] I have not forgotten you. I am still stuck with your bug: The mite transfers the first 8000 bytes and after does nothing; no interrupt is generated by the mite so as to finally awake your application. It seems like the data retrieved by the mite are not consumed by the board. Are you sure the digital output lines correspond to what you configured with cmd_bits ? I think the digital output is misconfigured. I am working on it. -Stefan On Jun 27, 2010, at 3:37, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi Alexis, thanks so much for the new analogy software. Here are some first observations: 1) cmd_bits.c works fine on our NI6250 board 2) however, a slightly modified version hangs -- I appended my cmd_bits.c to this email. All what I added is a for loop around the a4l_async_write() and a4l_snd_insn() commands, i.e., I wanted to trigger a write repeatedly. Look for the sschaal comment in my modified cmd_bits.c . After 32 iterations, cmd_bits hangs, no error messages in dmesg. Interesting, when I change your trigger_threshold variable from 128 to 256, my loop runs for 16 iterations (other changes of the trigger threshold adjust the number of iterations I get in a similar way). Thus, it feels like there is a buffer which does not get reset after a4l_snd_insn() is called -- does this make sense? Could you tell me if the mite triggered an interrupt ? Could you send a dump of cat /proc/xenomai/irq after having made the test program hang ? Many thanks, Best wishes, -Stefan On Jun 24, 2010, at 15:43, Alexis Berlemont wrote: Hi, Alexis Berlemont wrote: Hi Stefan, Stefan Schaal wrote: Hi Alexis, I was just wondering whether the new experimental branch in your git repository is something that can be tried already. No. Not yet. This branch is aimed at temporarily holding the corrections I am trying to do for the cmd_bits issue. It needs quite a lot of work and I have not finished yet. If you have a look at the commits in this branch, we will see many (broken). I just rebased the experimental branch into the branch analogy. So, starting from now, we should be able to properly use cmd_bits with a clone of my git repository. After having reworked the asynchronous buffer subsystem (and having fixed some oops in the NI driver and in the new code), cmd_bits can correctly communicate with the DIO subdevice. A command like ./cmd_bits 0x 0x works on my board. Unfortunately, I have not done the necessary to check the digital output lines yet. Best wishes, -Stefan -- Alexis. -- Alexis. === cmd_bits.c == -- Alexis. -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] analogy - experimental branch
Hi, Stefan Schaal wrote: Hi Alexis, thanks so much for the new analogy software. Here are some first observations: 1) cmd_bits.c works fine on our NI6250 board 2) however, a slightly modified version hangs -- I appended my cmd_bits.c to this email. All what I added is a for loop around the a4l_async_write() and a4l_snd_insn() commands, i.e., I wanted to trigger a write repeatedly. Look for the sschaal comment in my modified cmd_bits.c . After 32 iterations, cmd_bits hangs, no error messages in dmesg. Interesting, when I change your trigger_threshold variable from 128 to 256, my loop runs for 16 iterations (other changes of the trigger threshold adjust the number of iterations I get in a similar way). Thus, it feels like there is a buffer which does not get reset after a4l_snd_insn() is called -- does this make sense? Could you tell me if the mite triggered an interrupt ? Could you send a dump of cat /proc/xenomai/irq after having made the test program hang ? Many thanks, Best wishes, -Stefan On Jun 24, 2010, at 15:43, Alexis Berlemont wrote: Hi, Alexis Berlemont wrote: Hi Stefan, Stefan Schaal wrote: Hi Alexis, I was just wondering whether the new experimental branch in your git repository is something that can be tried already. No. Not yet. This branch is aimed at temporarily holding the corrections I am trying to do for the cmd_bits issue. It needs quite a lot of work and I have not finished yet. If you have a look at the commits in this branch, we will see many (broken). I just rebased the experimental branch into the branch analogy. So, starting from now, we should be able to properly use cmd_bits with a clone of my git repository. After having reworked the asynchronous buffer subsystem (and having fixed some oops in the NI driver and in the new code), cmd_bits can correctly communicate with the DIO subdevice. A command like ./cmd_bits 0x 0x works on my board. Unfortunately, I have not done the necessary to check the digital output lines yet. Best wishes, -Stefan -- Alexis. -- Alexis. === cmd_bits.c == -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] analogy - experimental branch
Hi Alexis, I did a reboot, ran my modified cmd_bits.c again one time. cat /proc/xenomai/irq reports: IRQ CPU0CPU1CPU2CPU3CPU4CPU5 CPU6CPU7 56: 0 0 0 0 0 0 0 0 Analogy device 518: 0 1 1 1 1 1 1 1 [IPI] 521: 626392 618020 618539 620274 617326 625008 622464 626300 [timer] 522: 0 0 0 0 0 0 0 0 [critical sync] 546: 0 0 0 0 0 0 0 0 [virtual] -Stefan On Jun 27, 2010, at 3:37, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi Alexis, thanks so much for the new analogy software. Here are some first observations: 1) cmd_bits.c works fine on our NI6250 board 2) however, a slightly modified version hangs -- I appended my cmd_bits.c to this email. All what I added is a for loop around the a4l_async_write() and a4l_snd_insn() commands, i.e., I wanted to trigger a write repeatedly. Look for the sschaal comment in my modified cmd_bits.c . After 32 iterations, cmd_bits hangs, no error messages in dmesg. Interesting, when I change your trigger_threshold variable from 128 to 256, my loop runs for 16 iterations (other changes of the trigger threshold adjust the number of iterations I get in a similar way). Thus, it feels like there is a buffer which does not get reset after a4l_snd_insn() is called -- does this make sense? Could you tell me if the mite triggered an interrupt ? Could you send a dump of cat /proc/xenomai/irq after having made the test program hang ? Many thanks, Best wishes, -Stefan On Jun 24, 2010, at 15:43, Alexis Berlemont wrote: Hi, Alexis Berlemont wrote: Hi Stefan, Stefan Schaal wrote: Hi Alexis, I was just wondering whether the new experimental branch in your git repository is something that can be tried already. No. Not yet. This branch is aimed at temporarily holding the corrections I am trying to do for the cmd_bits issue. It needs quite a lot of work and I have not finished yet. If you have a look at the commits in this branch, we will see many (broken). I just rebased the experimental branch into the branch analogy. So, starting from now, we should be able to properly use cmd_bits with a clone of my git repository. After having reworked the asynchronous buffer subsystem (and having fixed some oops in the NI driver and in the new code), cmd_bits can correctly communicate with the DIO subdevice. A command like ./cmd_bits 0x 0x works on my board. Unfortunately, I have not done the necessary to check the digital output lines yet. Best wishes, -Stefan -- Alexis. -- Alexis. === cmd_bits.c == -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] analogy - experimental branch
Hi Alexis, thanks so much for the new analogy software. Here are some first observations: 1) cmd_bits.c works fine on our NI6250 board 2) however, a slightly modified version hangs -- I appended my cmd_bits.c to this email. All what I added is a for loop around the a4l_async_write() and a4l_snd_insn() commands, i.e., I wanted to trigger a write repeatedly. Look for the sschaal comment in my modified cmd_bits.c . After 32 iterations, cmd_bits hangs, no error messages in dmesg. Interesting, when I change your trigger_threshold variable from 128 to 256, my loop runs for 16 iterations (other changes of the trigger threshold adjust the number of iterations I get in a similar way). Thus, it feels like there is a buffer which does not get reset after a4l_snd_insn() is called -- does this make sense? Best wishes, -Stefan On Jun 24, 2010, at 15:43, Alexis Berlemont wrote: Hi, Alexis Berlemont wrote: Hi Stefan, Stefan Schaal wrote: Hi Alexis, I was just wondering whether the new experimental branch in your git repository is something that can be tried already. No. Not yet. This branch is aimed at temporarily holding the corrections I am trying to do for the cmd_bits issue. It needs quite a lot of work and I have not finished yet. If you have a look at the commits in this branch, we will see many (broken). I just rebased the experimental branch into the branch analogy. So, starting from now, we should be able to properly use cmd_bits with a clone of my git repository. After having reworked the asynchronous buffer subsystem (and having fixed some oops in the NI driver and in the new code), cmd_bits can correctly communicate with the DIO subdevice. A command like ./cmd_bits 0x 0x works on my board. Unfortunately, I have not done the necessary to check the digital output lines yet. Best wishes, -Stefan -- Alexis. -- Alexis. === cmd_bits.c == cmd_bits.c Description: Binary data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] analogy - experimental branch
Hi, Alexis Berlemont wrote: Hi Stefan, Stefan Schaal wrote: Hi Alexis, I was just wondering whether the new experimental branch in your git repository is something that can be tried already. No. Not yet. This branch is aimed at temporarily holding the corrections I am trying to do for the cmd_bits issue. It needs quite a lot of work and I have not finished yet. If you have a look at the commits in this branch, we will see many (broken). I just rebased the experimental branch into the branch analogy. So, starting from now, we should be able to properly use cmd_bits with a clone of my git repository. After having reworked the asynchronous buffer subsystem (and having fixed some oops in the NI driver and in the new code), cmd_bits can correctly communicate with the DIO subdevice. A command like ./cmd_bits 0x 0x works on my board. Unfortunately, I have not done the necessary to check the digital output lines yet. Best wishes, -Stefan -- Alexis. -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] analogy - experimental branch
Hi Alexis, I was just wondering whether the new experimental branch in your git repository is something that can be tried already. Best wishes, -Stefan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
