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
