Re: [Xenomai-core] Analogy DIO data acquisition with NI6259

2011-09-13 Thread Stefan Schaal
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

2011-05-12 Thread Stefan Schaal
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

2011-01-07 Thread Stefan Schaal
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

2011-01-06 Thread Stefan Schaal
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

2010-12-29 Thread Stefan Schaal
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

2010-12-25 Thread Stefan Schaal
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

2010-10-15 Thread Stefan Schaal
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

2010-09-08 Thread Stefan Schaal
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

2010-09-02 Thread Stefan Schaal
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

2010-08-24 Thread Stefan Schaal
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

2010-07-19 Thread Stefan Schaal
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

2010-07-15 Thread Stefan Schaal
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

2010-07-14 Thread Stefan Schaal
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

2010-07-13 Thread Stefan Schaal
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

2010-07-12 Thread Stefan Schaal
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

2010-07-12 Thread Stefan Schaal
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

2010-07-09 Thread Stefan Schaal
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

2010-07-06 Thread Stefan Schaal
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

2010-06-27 Thread Stefan Schaal
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

2010-06-25 Thread Stefan Schaal
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

2010-06-02 Thread Stefan Schaal
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

2010-03-03 Thread Stefan Schaal
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

2010-03-02 Thread Stefan Schaal
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

2010-02-18 Thread Stefan Schaal
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

2009-12-22 Thread Stefan Schaal
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

2009-12-22 Thread Stefan Schaal
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

2009-12-21 Thread Stefan Schaal
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?

2009-11-02 Thread Stefan Schaal
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?

2009-11-02 Thread Stefan Schaal
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?

2009-11-01 Thread Stefan Schaal
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

2009-10-29 Thread Stefan Schaal
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