Re: [Xenomai-core] Analogy DIO data acquisition with NI6259
This is a summary and conclusion of using a NI6259 with Xenomai/Analogy for digital data I/O. First of all, many thanks to Alexis whose Analogy branch really allowed us to succeed! We would just like share the final results of our implementation with the hope that this might help others. Goals: We needed a 19 bit parallel I/O for bi-directional communication between a host computer and a robot controller. The 32bit DIO of the NI6259 seemed to well suited. The communication protocol needs about 300 DIO commands per ms, where every about 20 commands the DIO port needs to switch from write to read and then back. Problems: Initially we tried a4l_sync_dio() (synchronous communication). We measured that one a4l_sync_dio() takes about 5us. Additionally, the switch from read to write mode also seems to take some additional time. Thus, the communication speed was not sufficient. A 2nd attempt was to use instructions and instruction lists using a4l_snd_insnlist() and a4l_snd_insn(). We measure that this can bring down one data acquisition to about 3.5us when all commands are queued up in an instruction list, but due to the read/write switch we needed, we cannot use very long instruction lists, and the read/write switch takes too long. Thus, the communication speed did not improve a lot. A 3rd attempt was to use CMD structures. Following comedi examples, we create a 200ns clock and triggered the CMD streaming with this clock. This allows VERY fast DIO. But, again, the read/write switches that are needed frequently made CMD structures inefficient as we could not cue up a lot of DIO commands before the next read/write switch, and in order to do the read/write switch, the CMD has to be aborted. We also noted that starting a CMD has some delays. We realized that none of these approaches was feasible. Solution: We create a simple IC-based circuit that allowed to branch the read/write DIO protocol such that we could use one DIO channel of the NI6259 for write only (never switched to read), and the 2nd DIO channel on the NI6259 for read only (no switching). By avoiding the read/write switching, all three ideas from above are possible and run fast enough (after some optimization of our communication protocol). We ended up using a4l_sync_dio() as it is the easiest to use, and yielded sufficient speed. With the CMD approach, we would be able to go a factor 5-10 faster even. For you info, our interface C-code is attached. This is not general purpose software, but should allow other to get the idea of what we do. Best wishes, and thanks again to Alexis! -Stefan ni6259_interface.c Description: Binary data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] analogy: wake-up threshold
Hi Alexis, thanks so much for the new feature! I will try it and report back. In the last months, I actually did run some comparisons between Comedi and Analogy, and in all cases found that your Analogy implementation performs exactly the same as Comedi, actually, for CMD-based streaming, I noticed shorter latencies in Analogy. I also couldn't find any Comedi functionality (for our problems) that was missing in Analogy. Thus, for our work, there may simply be an issue that the communication protocol we are porting from vxWorks may not easily be implemented with our NI6259 board using either Comedi or Analogy, and we are considering to change the protocol with the help of some intermediate electronics. After all is working, I will email the method of solution to the xenomai-core list. But I am eager to check your new functions. Best wishes, -Stefan On May 12, 2011, at 15:52, Alexis Berlemont wrote: Hi Stefan, A few months ago, you asked me whether it was possible to prevent the OS from waking up your process each time a few bytes were acquired. You came with the idea to implement a wake-up threshold below which the user space process is kept in sleep state. A few days ago, I updated my experimental branch: two new user-space functions were added: a4l_set_wakesize() and a4l_get_wakesize(). Thanks to them, you will be able to configure the wished behaviour. I hope this will help you. -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] CMD based acquisition with Analogy
Hi Alexis, here is an observation with CMD-based acquisition that puzzles me. Just to recall, we use an NI6259 board, using your latest analogy branch of xenomai on a 2.6.29.5 kernel in Ubuntu 9.10. Our computer is a 32bit Dell Precision with 8 core Xeon processors. A normal CMD based acquisition with internal trigger has the core elements as listed below. What puzzles me that it appears from my tests that the triggering of the acquisition with a4l_snd_insn(desc, insn) seems to take about 200-300 us to complete. This is a very long time for us, as we need to start and stop a CMD based acquisition multiple times in our code. Thus, my question is simply whether this long latency is normal from your experience? I used other a4l_snd_insn commands for INSN based data acquisition before (and I believe your sync data acquisition uses INSN, too), but always had 3-5us duration for these commands. Best wishes, -Stefan // // fill out data structures a4l_cmd_t cmd = { .idx_subd = ID_SUBDEV_DIGITAL, .flags = 0, .start_src = TRIG_INT,// internal trigger .start_arg = 0, .scan_begin_src = TRIG_EXT, .scan_begin_arg = NI_CDIO_SCAN_BEGIN_SRC_G0_OUT, // channel used to trigger the scans .convert_src = TRIG_NOW, .convert_arg = 0, /* in ns */ .scan_end_src = TRIG_COUNT, .scan_end_arg = 32, .stop_src = TRIG_NONE, .stop_arg = 0, .nb_chan = 32, .chan_descs = chans, }; a4l_insn_t insn = { .type = A4L_INSN_INTTRIG, .idx_subd = ID_SUBDEV_DIGITAL, .data_size = 0, }; // send command rc = a4l_snd_command(desc, cmd); if (rc 0) printf(ni_test: a4l_snd_command failed (ret=%d)\n, rc); } // add some date to FIFO buffer // trigger acquisition rc = a4l_snd_insn(desc, insn); if (rc 0) printf(ni_test: triggering failed (rc=%d)\n,rc); // ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] hanging in Xenomai 2.5.5
Hi Philippe, thanks a lot for the hint. I configured my kernel from scratch, and got rid of the linux compile problems. I could thus verify that the commit you mentioned below DOES NOT have the problem I described, i.e., semaphores used by multiple processes which are running on different cores DID NOT hang anymore. Then, I thought I try to bisect the problem with git, and I pulled the latest version of the 2.5 repository. Interestingly, with the very latest commits, my problem has gone away. I confirmed this by switching back to Alexis' analogy branch, which I need for my development. This branch is not quite as up-to-date as the 2.5 branch, and the hanging problem still exists. I merged the analogy branch with the latest 2.5 branch, and now nothing hangs anymore. I guess, I stop investigating at this point, unless the problem re-apprears. Thanks so much for you help! Best wishes, -Stefan On Jan 5, 2011, at 7:53, Philippe Gerum wrote: On Wed, 2011-01-05 at 07:41 -0800, Stefan Schaal wrote: HI Philippe, sorry, I must have mis-communicated. This was, of course, a xenomai commit that I tried, and the errors I sent you resulted when recompiling the linux kernel with this xenomai version. Those errors are not related to Xenomai, they happen on basic linux code. Make sure to work from a fresh build tree, using a proper toolchain. It looks like something is severely broken in your build env. -Stefan On Jan 5, 2011, at 6:07, Philippe Gerum wrote: On Sat, 2010-12-25 at 11:02 -0800, Stefan Schaal wrote: 6a020f5 I don't see how this messages could be related to Xenomai. I was mentioning a Xenomai commit, not a linux one. You should reset to this commit: commit 6a020f5a89955a42f1e03621ae6c63a587e9c75c Author: Philippe Gerum r...@xenomai.org Date: Sat Aug 28 13:04:45 2010 +0200 nucleus, posix: use fast APC scheduling call -- Philippe. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Analogy DIO data acquisition
Hi Alexis, I was wondering whether you could help me with some information about CMD based data acquisition in analogy. You might recall from previous emails with you, we are trying to implement high speed data DIO communication with a NI6259 board. We use the CMD structure to create a periodic task, that is clocked by a timer, to achieve the required communication speed. As we need to change the R/W polarity on some channels every 20-30 scans, we need essentially to find out when the data in the communication buffer are consumed, such that we change polarity and trigger the next set of acquisitions. Currently, working with the MMAP options seems to be the best way of handling this. I just had some questions concerning how to detect when the data are consumed. It appears that the periodic task is automatically canceled when a DMA underun is discovered (as can be checked with dmesg). Is this automatic canceling behavior the officially correct behavior? I can use a4l_poll to find out how much data is left in the communication buffer --- I noticed that it returns -EPIPE when the data buffer has been consumed, which also seems to indicate that the periodic task has been canceled. (So for, the -EPIPE return code is not documented in Analogy). I am running your latest Analogy branch. I was just wondering whether my observations are correct, and that it makes sense to develop more communication code by using this behavior of Analogy. Best wishes, and Happy Holidays! -Stefan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] hanging in Xenomai 2.5.5
Hi Phiippe, thanks so much for your replay -- it took me a moment to get back to this problem. Here are some first observations: 1) the problem only occurs when I distribute the communicating processes over multiple cores -- in Xenomai 2.5.4, this has never been a problem. 2) The /proc/xenomai/stat looks like: CPU PIDMSWCSWPFSTAT %CPU NAME 0 0 0 23492290 00500080 100.0 ROOT/0 1 0 0 20328410 0 00500080 100.0 ROOT/1 2 0 0 10403210 00500080 100.0 ROOT/2 3 0 0 445786 0 00500080 100.0 ROOT/3 4 0 0 71162 0 00500080 100.0 ROOT/4 5 0 0 0 0 00500080 100.0 ROOT/5 6 0 0 0 0 00500080 100.0 ROOT/6 7 0 0 0 0 00500080 100.0 ROOT/7 1 3128 0 91261 0 003001820.0 sem1_task 2 3166 0 90470 0 003001880.0 sem2_task 3 3195 0 45237 0 003001820.0 sem3_task 0 0 0 0 0 0.0 IRQ56: Analogy device 1 0 0 0 0 0.0 IRQ56: Analogy device 2 0 0 0 0 0.0 IRQ56: Analogy device 3 0 0 0 0 0.0 IRQ56: Analogy device 4 0 0 0 0 0.0 IRQ56: Analogy device 5 0 0 0 0 0.0 IRQ56: Analogy device 6 0 0 0 0 0.0 IRQ56: Analogy device 7 0 0 0 0 0.0 IRQ56: Analogy device 1 0 0 39326230 0 0.0 IRQ521: [timer] 2 0 0 16415320 0.0 IRQ521: [timer] 3 0 0 12585710 0.0 IRQ521: [timer] 4 0 0 722843 0 0.0 IRQ521: [timer] 5 0 0 780591 0 0.0 IRQ521: [timer] 6 0 0 764817 0 0.0 IRQ521: [timer] 7 0 0 385421 0 0.0 IRQ521: [timer] The three communicating processes are sem1_task, sem2_task, sem3_task -- they are currently hanging with 0% CPU 3) the /proc/xenomai/sched look like: CPU PIDCLASS PRI TIMEOUT TIMEBASE STAT NAME 0 0 idle-1 - master R ROOT/0 1 0 idle-1 - master R ROOT/1 2 0 idle-1 - master R ROOT/2 3 0 idle-1 - master R ROOT/3 4 0 idle-1 - master R ROOT/4 5 0 idle-1 - master R ROOT/5 6 0 idle-1 - master R ROOT/6 7 0 idle-1 - master R ROOT/7 1 3128 rt 50 - master W sem1_task 2 3166 rt 50 - master R sem2_task 3 3195 rt 50 - master W sem3_task Interestingly, despite sem2_task is supposed to be running, it doesn't. 4) When I try to terminate the three processes, sem2_task would hand and I cannot kill it. Interestingly, if I start another program that does a similar semaphore communication, sem2_task is finally released. Indeed, when I start this other program, the three processes (sem1_task, sem2_task, sem3_task) start running again, until they hang again. 5) I appended the little test program I used -- it is called xtest_xeno_sem.c I compile with: gcc -o xtest -I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -D__XENO__ -lnative -L/usr/xenomai/lib -lxenomai -lpthread -lrt -lrtdk -lnative test_xeno_sem.c To create three communicating processes on different cores, I execute: terminal1 xtest 1 1 terminal2 xtest 2 1 terminal3 xtest 3 1 To create three communicating processes on ONE core, I execute: terminal1 xtest 1 0 terminal2 xtest 2 0 terminal3 xtest 3 0 6) I haven't tested the other commits yet -- this comes next. But maybe the information above already tells you all you need to know. Best wishes, and, as always, a thousand thanks for your kind help! -Stefan --- test_xeno_sem.c test_xeno_sem.c Description: Binary data On Oct 16, 2010, at 1:48, Philippe Gerum wrote: On Fri, 2010-10-15 at 22:43 -0700, Stefan Schaal wrote: Hi everybody, here is a quick first report on an issue that appeared with Xenomai 2.5.5 --- NOTE: 2.5.4 (and earlier) DOES NOT have this issue. We run multiple real-time
[Xenomai-core] hanging in Xenomai 2.5.5
Hi everybody, here is a quick first report on an issue that appeared with Xenomai 2.5.5 --- NOTE: 2.5.4 (and earlier) DOES NOT have this issue. We run multiple real-time processes, synchronized by semaphores and interprocess communication using shared memory. All is cleanly implemented using the xenomai real-time functions, no mode switches. The different processes are distributed on different processors of our multi-core machine using rt_task_spawn() with the T_CPU directive. Up to version 2.5.4, this worked fine. With version 2.5.5 (and 2.5.5.1), the processes hang after a few seconds of running (CPU consumption goes to zero), and usually one of them hangs so badly that it cannot be killed anymore with kill -9 -- thus reboot is required. The problems happens on BOTH our i386 machine (Dell 8-core, ubuntu 9.04, kernel 2.6.29.5) AND x86_64 machine (Dell 8 core, ubuntu 9.10, kernel 2.6.31.4). Thus, this seems to be specific to the xenomai release 2.5.5 and higher. No dmesg print-outs when this error occurs. We will try to create a simple test program to illustrate the problem, but maybe the issue is already obvious to some of the experts on this list. Best wishes, -Stefan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
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
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
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
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
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 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
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 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
[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
Re: [Xenomai-core] Analogy DIO speed
Hi Alexis, thanks a lot or the reply. Just to check: is it possible to use commands with digital subdevices at all? I am not sure whether I understood your comment below correctly. Are your *currently* working to enable commands for DIO subdevices? Thanks a lot! -Stefan On Mar 3, 2010, at 15:58, Alexis Berlemont wrote: Hi Stefan, Sorry for the late reply, I was unavailable yesterday. Stefan Schaal wrote: Hi Alexis, we pulled your analogy branch, and now cmd_write works. Great, and thanks a lot! Next, I tried to use commands with the digital IO subdevice on our board (subdevice #2), but the get an error message: [ 2482.771913] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported Unfortunately, cmd_write was not designed to work with digital subdevices; the command's fields are not appropriate, I am trying to make it work quite quickly. Is there just missing support for the DIO subdevices using commands? Best wishes, -Stefan ps.: feel free to use our machine for debugging -- it now has the latest version of your software installed with linux kernel 2.6.29.5. On Feb 28, 2010, at 16:24, Alexis Berlemont wrote: Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi Alexis, On Feb 18, 2010, at 14:34, Alexis Berlemont wrote: I have some problems with implementing commands on my NI6259 so far. Could you remind me what was the problem ? See the print-outs below for the problem we have. Thanks so much for looking into this! -Stefan Using the cmd_write() function that you provide in analogy, we get the following problem: I am currently trying to fix this bug, which is not that easy. I just have one question (that I remember I have already asked you in some way, but I just want to be sure): Does this bug occur the very first time you launched cmd_write (I mean after a reboot) ? I managed at last to fix the bug you were facing (at least I hope so). The problem was located in the trigger callback which waited for a bit-status (fifo half full) before going further; however, sometimes the DMA interrupt already occurred and cleaned everything behind your back. I have not made a pull request because the current implementation is not perfect. If you have some time, could you clone my git repository (branch: analogy) and check that a simple call to cmd_write does not trigger the bug anymore ? Many thanks. r...@xenomai:/usr/src/xenomai/src/utils/analogy# ./cmd_write -v cmd_write: device analogy0 opened (fd=0) cmd_write: basic descriptor retrieved subdevices count = 14 read subdevice index = 0 write subdevice index = 1 cmd_write: complex descriptor retrieved cmd_write: channel 0 ranges count = 3 range's size = 16 (bits) cmd_write: channel 1 ranges count = 3 range's size = 16 (bits) cmd_write: scan size = 4 cmd_write: size to write = 400 cmd_write: command successfully sent cmd_write: triggering failed (ret=-32) r...@xenomai:/usr/src/xenomai/src/utils/analogy# dmesg -c [133345.213865] Analogy: analogy_ni_pcimio: ni_mio_common: interrupt: b_status=0002 m1_status=80a8 [133345.332719] Analogy: analogy_ni_pcimio: ni_ao_wait_for_dma_load: timed out waiting for dma load3Analogy: a4l_do_special_insn: execution of the instruction failed (err=-32) Another problem we have is with the --mmap option: r...@xenomai:/usr/src/xenomai/src/utils/analogy# ./cmd_write -v --mmap cmd_write: device analogy0 opened (fd=0) cmd_write: basic descriptor retrieved subdevices count = 14 read subdevice index = 0 write subdevice index = 1 cmd_write: complex descriptor retrieved cmd_write: channel 0 ranges count = 3 range's size = 16 (bits) cmd_write: channel 1 ranges count = 3 range's size = 16 (bits) cmd_write: scan size = 4 cmd_write: size to write = 400 cmd_write: buffer size = 65536 bytes cmd_write: a4l_mmap() failed (ret=-22) r...@xenomai:/usr/src/xenomai/src/utils/analogy# dmesg -c [133408.942998] Analogy: a4l_ioctl_mmap: mmap not allowed on this subdevice Alexis. Alexis. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy DIO speed
Hi Alexis, we pulled your analogy branch, and now cmd_write works. Great, and thanks a lot! Next, I tried to use commands with the digital IO subdevice on our board (subdevice #2), but the get an error message: [ 2482.771913] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported Is there just missing support for the DIO subdevices using commands? Best wishes, -Stefan ps.: feel free to use our machine for debugging -- it now has the latest version of your software installed with linux kernel 2.6.29.5. On Feb 28, 2010, at 16:24, Alexis Berlemont wrote: Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi Alexis, On Feb 18, 2010, at 14:34, Alexis Berlemont wrote: I have some problems with implementing commands on my NI6259 so far. Could you remind me what was the problem ? See the print-outs below for the problem we have. Thanks so much for looking into this! -Stefan Using the cmd_write() function that you provide in analogy, we get the following problem: I am currently trying to fix this bug, which is not that easy. I just have one question (that I remember I have already asked you in some way, but I just want to be sure): Does this bug occur the very first time you launched cmd_write (I mean after a reboot) ? I managed at last to fix the bug you were facing (at least I hope so). The problem was located in the trigger callback which waited for a bit-status (fifo half full) before going further; however, sometimes the DMA interrupt already occurred and cleaned everything behind your back. I have not made a pull request because the current implementation is not perfect. If you have some time, could you clone my git repository (branch: analogy) and check that a simple call to cmd_write does not trigger the bug anymore ? Many thanks. r...@xenomai:/usr/src/xenomai/src/utils/analogy# ./cmd_write -v cmd_write: device analogy0 opened (fd=0) cmd_write: basic descriptor retrieved subdevices count = 14 read subdevice index = 0 write subdevice index = 1 cmd_write: complex descriptor retrieved cmd_write: channel 0 ranges count = 3 range's size = 16 (bits) cmd_write: channel 1 ranges count = 3 range's size = 16 (bits) cmd_write: scan size = 4 cmd_write: size to write = 400 cmd_write: command successfully sent cmd_write: triggering failed (ret=-32) r...@xenomai:/usr/src/xenomai/src/utils/analogy# dmesg -c [133345.213865] Analogy: analogy_ni_pcimio: ni_mio_common: interrupt: b_status=0002 m1_status=80a8 [133345.332719] Analogy: analogy_ni_pcimio: ni_ao_wait_for_dma_load: timed out waiting for dma load3Analogy: a4l_do_special_insn: execution of the instruction failed (err=-32) Another problem we have is with the --mmap option: r...@xenomai:/usr/src/xenomai/src/utils/analogy# ./cmd_write -v --mmap cmd_write: device analogy0 opened (fd=0) cmd_write: basic descriptor retrieved subdevices count = 14 read subdevice index = 0 write subdevice index = 1 cmd_write: complex descriptor retrieved cmd_write: channel 0 ranges count = 3 range's size = 16 (bits) cmd_write: channel 1 ranges count = 3 range's size = 16 (bits) cmd_write: scan size = 4 cmd_write: size to write = 400 cmd_write: buffer size = 65536 bytes cmd_write: a4l_mmap() failed (ret=-22) r...@xenomai:/usr/src/xenomai/src/utils/analogy# dmesg -c [133408.942998] Analogy: a4l_ioctl_mmap: mmap not allowed on this subdevice Alexis. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy DIO speed
Hi Alexis, On Feb 18, 2010, at 14:34, Alexis Berlemont wrote: I have some problems with implementing commands on my NI6259 so far. Could you remind me what was the problem ? See the print-outs below for the problem we have. Thanks so much for looking into this! -Stefan Using the cmd_write() function that you provide in analogy, we get the following problem: r...@xenomai:/usr/src/xenomai/src/utils/analogy# ./cmd_write -v cmd_write: device analogy0 opened (fd=0) cmd_write: basic descriptor retrieved subdevices count = 14 read subdevice index = 0 write subdevice index = 1 cmd_write: complex descriptor retrieved cmd_write: channel 0 ranges count = 3 range's size = 16 (bits) cmd_write: channel 1 ranges count = 3 range's size = 16 (bits) cmd_write: scan size = 4 cmd_write: size to write = 400 cmd_write: command successfully sent cmd_write: triggering failed (ret=-32) r...@xenomai:/usr/src/xenomai/src/utils/analogy# dmesg -c [133345.213865] Analogy: analogy_ni_pcimio: ni_mio_common: interrupt: b_status=0002 m1_status=80a8 [133345.332719] Analogy: analogy_ni_pcimio: ni_ao_wait_for_dma_load: timed out waiting for dma load3Analogy: a4l_do_special_insn: execution of the instruction failed (err=-32) Another problem we have is with the --mmap option: r...@xenomai:/usr/src/xenomai/src/utils/analogy# ./cmd_write -v --mmap cmd_write: device analogy0 opened (fd=0) cmd_write: basic descriptor retrieved subdevices count = 14 read subdevice index = 0 write subdevice index = 1 cmd_write: complex descriptor retrieved cmd_write: channel 0 ranges count = 3 range's size = 16 (bits) cmd_write: channel 1 ranges count = 3 range's size = 16 (bits) cmd_write: scan size = 4 cmd_write: size to write = 400 cmd_write: buffer size = 65536 bytes cmd_write: a4l_mmap() failed (ret=-22) r...@xenomai:/usr/src/xenomai/src/utils/analogy# dmesg -c [133408.942998] Analogy: a4l_ioctl_mmap: mmap not allowed on this subdevice ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] cmd_write
Hi, I have been trying to test the functionality of the analogy_ni_pcimio driver on a NI6259 board. I am using a linux kernel 2.6.29.5 with the xenomai-head (rc5). Doing an a4l_sync_write to an analog output channel works fine. Now I am trying to use the cmd structure for writing to the same analog output channel, as done in the cmd_write progam (whose source I found in xenomai_root/src/util/analogy/cmd_write.c . But I am getting the error as indicated below. Any idea why this happens? My own programming gets the same error. Thanks a lot! -Stefan unix /usr/xenomai/bin/cmd_write -v -d analogy0 -s 1 -c 0 -S 1 cmd_write: device analogy0 opened (fd=0) cmd_write: basic descriptor retrieved subdevices count = 14 read subdevice index = 0 write subdevice index = 1 cmd_write: complex descriptor retrieved cmd_write: channel 0 ranges count = 3 range's size = 16 (bits) cmd_write: scan size = 2 cmd_write: size to write = 2 cmd_write: command successfully sent cmd_write: triggering failed (ret=-32) ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] cmd_write
dmesg: Analogy: analogy_ni_pcimio: ni_mio_common: interrupt: b_status=0002 m1_status=80a8 [15619.322973] Analogy: analogy_ni_pcimio: ni_ao_wait_for_dma_load: timed out waiting for dma load -Stefan On Dec 22, 2009, at 16:52, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi, I have been trying to test the functionality of the analogy_ni_pcimio driver on a NI6259 board. I am using a linux kernel 2.6.29.5 with the xenomai-head (rc5). Doing an a4l_sync_write to an analog output channel works fine. Now I am trying to use the cmd structure for writing to the same analog output channel, as done in the cmd_write progam (whose source I found in xenomai_root/src/util/analogy/cmd_write.c . But I am getting the error as indicated below. Any idea why this happens? My own programming gets the same error. Thanks a lot! -Stefan unix /usr/xenomai/bin/cmd_write -v -d analogy0 -s 1 -c 0 -S 1 cmd_write: device analogy0 opened (fd=0) cmd_write: basic descriptor retrieved subdevices count = 14 read subdevice index = 0 write subdevice index = 1 cmd_write: complex descriptor retrieved cmd_write: channel 0 ranges count = 3 range's size = 16 (bits) cmd_write: scan size = 2 cmd_write: size to write = 2 cmd_write: command successfully sent cmd_write: triggering failed (ret=-32) Is there any kernel error messages ? Could you give us the last few lines of `dmesg` ? ___ 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] digital I/O with analgoy using ni_pcmcia
Hi Alexis, thanks a lot for all these suggestions. For my applications, the functions you listed below would be entirely sufficient. Essentially, I need to be able to put selected channels on the DIO in either read or write mode, and then simply read from them or write from them. The protocol I use requires 16 data bits, and 3 additional control lines. It was originally implemented under vxWorks. Nothing fancy at all. Thanks a lot for your kind help! -Stefan On Dec 21, 2009, at 15:23, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi everybody, we have an NI6259 board working xenomai 2.5, using the analogy APIs. Read/write to analog channels is quite straightforward and can be inferred from the cmd_read and cmd_write source code. Now I would also like to use the digital I/O of this board (e.g., the 32 digital I/O lines). In Comedi, there are functions to set the DIO lines to input/output mode (comedi_dio_config), and then functions to read/write, like comedi_dio_read and comedi_dio_write. Does xenomai/analogy already have similar functionality? Many thanks for this question, it is an issue I have been keeping on postponing the resolution. Currently, the functions are not implemented but it could be quickly done. Here is my understanding of the Comedi DIO features; please, correct me if I am wrong. In Comedi, here is the list of functions related with DIO: - comedi_dio_read (insn_read or deprecated insn trigger) - comedi_dio_write (insn_write or deprecated insn trigger) - comedi_dio_config (insn_config or deprecated insn trigger) - comedi_dio_get_config (insn_config or deprecated trigger) - comedi_dio_bitfield (insn_bits or comedi_dio_read/write) - comedi_dio_bitfield2 (insn_bits or comedi_dio_read/write) The instruction insn_bits is a combination of a read operation and a write operation (that is why, the function comedi_dio_bitfield* call comedi_dio_read and comedi_dio_write if the driver does not provide an insn-bits handler). I had a look at many Comedi drivers and most of them register the handler insn_bits for the DIO subdevice. The instructions insn_read and insn_write are not oftenly used in DIO contexts. comedi_dio_bitfield() uses the insn_bits instruction. However, it only works with DIO subdevice limited to 32 channels; that was why comedi_dio_bitfield2() was introduced, this latter function contains one more argument so as to shift the bits. Consequently, we may need a more limited set of functions: - a4l_sync_dio(dsc, idx_subd, mask, buf) - a4l_sizeof_subd(dsc, idx_subd) - a4l_config_subd(dsc, idx_subd, idx_chan, cfg_type, *val) a4l_sync_dio() could work with any DIO subdevice (more or less than 32 channels). The last argument would be a pointer to a buffer which size should be defined thanks to a4l_sizeof_subd() (8, 16, 32, 64 or more bits). a4l_config_subd() could be used to configure the polarity of the DIO channels. The argument cfg_type could be set to DIO_INPUT, DIO_OUTPUT, DIO_QUERY. And, we could even imagine that this function would not be limited to DIO subdevice; so, the argument cfg_type could accept more values (SERIAL_CLOCK, BIDIRECTIONAL_DATA, SET_CLOCK_SRC, GET_CLOCK_SRC, etc.) How do you see this approach ? Do you (or anyone else) have a better solution in mind ? Best regards, Thanks a lot, -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] lots of mode switches in xenomai-head tree?
Hi Jan, we updated the git on Oct. 29 (3 days ago). We do use the posix skin, i.e., we use the xeno-config --posix-ldflags. This worked all fine without mode switches under Xenomai 2.4.8. My git does include 4a2cb7b817. I will try to reproduce the error in a test program. -Stefan On Nov 1, 2009, at 23:43, Jan Kiszka wrote: Stefan Schaal wrote: Hi, I am working with the latest xenomai-head tree (we need analogy for our NI board ...). Under Xenomai 2.4.8 our code did not have any mode switches. Using the xenomai-head, we get a lot of mode switches. Using he backtrace_symbols_fd, we get print-outs like: xsimulation[0x808553b] [0xe400] /usr/xenomai/lib/librtdk.so.0(assert_nrt+0x85)[0xb7fa2ea5] /usr/xenomai/lib/librtdk.so.0(__wrap_clock_gettime+0x17)[0xb7fa2ef7] xsimulation[0x807cd16] xsimulation[0x807d7fb] /usr/xenomai/lib/libnative.so.3[0xb7fab689] /lib/tls/i686/cmov/libpthread.so.0[0xb7f824ff] /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7e8f49e] Which indicates that the wrapper for clock_gettime causes this trouble, which is also confirmed by commenting clock_gettime out, and the mode switches disappear. Maybe something that needs fixing? Do you wrap link against the POSIX library, ie. use that skin as well? If not, your code is actually using clock_gettime incorrectly as it then falls back to the Linux service which can trigger syscalls (or even deadlocks when the TSC is used). If you do use libpthread_rt, then my next question is if your work is based on today's git head or some older version not including 4a2cb7b817. Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] lots of mode switches in xenomai-head tree?
Hi Jan, you pointer to the 4a2cb7b817 help! We had -lrtdk before - lpthread -lpthread_rt in our compile statement. Just in 2.4.8, this seems to make no difference. -Stefan On Nov 2, 2009, at 10:42, Stefan Schaal wrote: Hi Jan, we updated the git on Oct. 29 (3 days ago). We do use the posix skin, i.e., we use the xeno-config --posix-ldflags. This worked all fine without mode switches under Xenomai 2.4.8. My git does include 4a2cb7b817. I will try to reproduce the error in a test program. -Stefan On Nov 1, 2009, at 23:43, Jan Kiszka wrote: Stefan Schaal wrote: Hi, I am working with the latest xenomai-head tree (we need analogy for our NI board ...). Under Xenomai 2.4.8 our code did not have any mode switches. Using the xenomai-head, we get a lot of mode switches. Using he backtrace_symbols_fd, we get print-outs like: xsimulation[0x808553b] [0xe400] /usr/xenomai/lib/librtdk.so.0(assert_nrt+0x85)[0xb7fa2ea5] /usr/xenomai/lib/librtdk.so.0(__wrap_clock_gettime+0x17)[0xb7fa2ef7] xsimulation[0x807cd16] xsimulation[0x807d7fb] /usr/xenomai/lib/libnative.so.3[0xb7fab689] /lib/tls/i686/cmov/libpthread.so.0[0xb7f824ff] /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7e8f49e] Which indicates that the wrapper for clock_gettime causes this trouble, which is also confirmed by commenting clock_gettime out, and the mode switches disappear. Maybe something that needs fixing? Do you wrap link against the POSIX library, ie. use that skin as well? If not, your code is actually using clock_gettime incorrectly as it then falls back to the Linux service which can trigger syscalls (or even deadlocks when the TSC is used). If you do use libpthread_rt, then my next question is if your work is based on today's git head or some older version not including 4a2cb7b817. Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] lots of mode switches in xenomai-head tree?
Hi, I am working with the latest xenomai-head tree (we need analogy for our NI board ...). Under Xenomai 2.4.8 our code did not have any mode switches. Using the xenomai-head, we get a lot of mode switches. Using he backtrace_symbols_fd, we get print-outs like: xsimulation[0x808553b] [0xe400] /usr/xenomai/lib/librtdk.so.0(assert_nrt+0x85)[0xb7fa2ea5] /usr/xenomai/lib/librtdk.so.0(__wrap_clock_gettime+0x17)[0xb7fa2ef7] xsimulation[0x807cd16] xsimulation[0x807d7fb] /usr/xenomai/lib/libnative.so.3[0xb7fab689] /lib/tls/i686/cmov/libpthread.so.0[0xb7f824ff] /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7e8f49e] Which indicates that the wrapper for clock_gettime causes this trouble, which is also confirmed by commenting clock_gettime out, and the mode switches disappear. Maybe something that needs fixing? Best wishes, -Stefan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH v2] build system: Fix shared libs generation
I tried the modified configure.in from the xenomai-head.git tree, but still the *.so libraries are not generated. This is on a x86 running the xenomai-2.5.rc4 under kernel 2.6.29.5. -Stefan Posted by Jan Kiszka on October 29, 2009 - 15:05: Philippe Gerum wrote: On Thu, 2009-10-29 at 12:33 +0100, Jan Kiszka wrote: This fixes a regression of dbbd33f50d: There must be no AC_DISABLE_SHARED without AS_ENABLE_SHARED for the cases where it shall remain enabled. Makes sense. Will you queue this in your tree? Done, it's ready to be pulled. Jan Signed-off-by: Jan Kiszka jan.kis...@xxx --- configure.in | 12 ++-- 1 files changed, 10 insertions(+), 2 deletions(-) v2: properly rebased against head diff --git a/configure.in b/configure.in index 40683fe..9cce885 100644 --- a/configure.in +++ b/configure.in @@ -117,7 +117,6 @@ case $build_for in XENO_LINUX_ARCH=nios2 XENO_LINUX_INSTALL_TARGET=install CONFIG_XENO_DEFAULT_PERIOD=1000 -AC_DISABLE_SHARED ;; *) echo echo *** @@ -128,9 +127,18 @@ case $build_for in esac AC_MSG_RESULT([$XENO_TARGET_ARCH]) -AC_PROG_LIBTOOL AM_CONDITIONAL(XENO_LINUX_ARCH_I386,[test $XENO_LINUX_ARCH = i386]) +case $XENO_TARGET_ARCH in + nios2) +AC_DISABLE_SHARED +;; + *) +AC_ENABLE_SHARED +;; +esac +AC_PROG_LIBTOOL + dnl dnl Parse options dnl -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core