[Xenomai-core] analogy - experimental branch

[Xenomai-core] analogy - experimental branch

[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

Re: [Xenomai-core] analogy - experimental branch

[Alexis Berlemont]

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)".

> Best wishes,
> 
> -Stefan

-- 
Alexis.

Re: [Xenomai-core] analogy - experimental branch

[Alexis Berlemont]

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 0xffff 0xffff" works on my
board. Unfortunately, I have not done the necessary to check the
digital output lines yet.
 

> > Best wishes,
> > 
> > -Stefan
> 
> -- 
> Alexis.

-- 
Alexis.

Re: [Xenomai-core] analogy - experimental branch

[Stefan Schaal]

[-- Attachment #1: Type: text/plain, Size: 2180 bytes --]

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 0xffff 0xffff" 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 ==================================================

[-- Attachment #2: cmd_bits.c --]
[-- Type: application/octet-stream, Size: 6942 bytes --]


/**
 * @file
 * Analogy for Linux, digital command test program
 *
 * @note Copyright (C) 1997-2000 David A. Schleef <ds@domain.hid>
 * @note Copyright (C) 2008 Alexis Berlemont <alexis.berlemont@domain.hid>
 *
 * Xenomai is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * Xenomai is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with Xenomai; if not, write to the Free Software Foundation,
 * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
 */

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <errno.h>
#include <getopt.h>

#include <analogy/analogy.h>

#define FILENAME "analogy0"

static char *filename = FILENAME;
static int verbose;

/* TODO: to be removed */
static unsigned int chans[4] = {0, 1, 2, 3};

/* 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,
};

struct option cmd_bits_opts[] = {
	{"verbose", no_argument, NULL, 'v'},
	{"device", required_argument, NULL, 'd'},
	{"subdevice", required_argument, NULL, 's'},
	{"help", no_argument, NULL, 'h'},
	{0},
};

void do_print_usage(void)
{
	fprintf(stdout, "usage:\tcmd_bits [OPTS] <bits_values> <mask>\n");
	fprintf(stdout, "\tOPTS:\t -v, --verbose: verbose output\n");
	fprintf(stdout,
		"\t\t -d, --device: "
		"device filename (analogy0, analogy1, ...)\n");
	fprintf(stdout, "\t\t -s, --subdevice: subdevice index\n");
	fprintf(stdout, "\t\t -h, --help: print this help\n");
}

int main(int argc, char *argv[])
{
	int i = 0, err = 0;
	a4l_desc_t dsc = { .sbdata = NULL };
	a4l_sbinfo_t *sbinfo;
	int scan_size, idx_subd = -1;
	int value, mask = 0;

	/* Trigger status, written data..., before triggering */
	int triggered = 0, total = 0, trigger_threshold = 128;

	/* Compute arguments */
	while ((err = getopt_long(argc,
				  argv,
				  "vd:s:h", cmd_bits_opts, NULL)) >= 0) {
		switch (err) {
		case 'v':
			verbose = 1;
			break;
		case 'd':
			filename = optarg;
			break;
		case 's':
			idx_subd = strtoul(optarg, NULL, 0);
			break;
		case 'h':
		default:
			do_print_usage();
			return 0;
		}
	}

	value = (argc - optind > 0) ? strtoul(argv[optind], NULL, 0) : 0;
	mask = (argc - optind > 1) ? strtoul(argv[optind + 1], NULL, 0) : 0;

	/* Open the device */
	err = a4l_open(&dsc, filename);
	if (err < 0) {
		fprintf(stderr,
			"cmd_bits: a4l_open %s failed (err=%d)\n",
			FILENAME, err);
		return err;
	}	

	if (verbose != 0) {
		printf("cmd_bits: device %s opened (fd=%d)\n",
		       filename, dsc.fd);
		printf("cmd_bits: basic descriptor retrieved\n");
		printf("\t subdevices count = %d\n", dsc.nb_subd);
		printf("\t read subdevice index = %d\n", dsc.idx_read_subd);
		printf("\t write subdevice index = %d\n", dsc.idx_write_subd);
	}	

	/* Allocate a buffer so as to get more info (subd, chan, rng) */
	dsc.sbdata = malloc(dsc.sbsize);
	if (dsc.sbdata == NULL) {
		fprintf(stderr, "cmd_bits: malloc failed \n");
		return -ENOMEM;
	}

	/* Get this data */
	err = a4l_fill_desc(&dsc);
	if (err < 0) {
		fprintf(stderr,
			"cmd_bits: a4l_get_desc failed (err=%d)\n", err);
		goto out_cmd_bits;
	}

	if (verbose != 0)
		printf("cmd_bits: complex descriptor retrieved\n");
	
	/* If no subdevice index was set, choose for the first digital
	   subdevice found */
	while (idx_subd == -1 && i < dsc.nb_subd) {
		
		err = a4l_get_subdinfo(&dsc, i, &sbinfo);
		if (err < 0) {
			fprintf(stderr, 
				"cmd_bits: "
				"a4l_get_subdinfo(%d) failed (err = %d)\n",
				i, err);
			goto out_cmd_bits;
		}
		
		if ((sbinfo->flags & A4L_SUBD_TYPES) == A4L_SUBD_DIO ||
		    (sbinfo->flags & A4L_SUBD_TYPES) == A4L_SUBD_DO) {
			idx_subd = i;
		}

		i++;
	}

	if (idx_subd == -1) {
		fprintf(stderr, "cmd_bits: no digital subdevice available\n");
		err = -EINVAL;
		goto  out_cmd_bits;
	}

	if (verbose != 0)
		printf("cmd_bits: selected subdevice index = %d\n", 
		       idx_subd);

	/* We must check that the subdevice is really a digital one
	   (in case, the subdevice index was set with the option -s) */
	err = a4l_get_subdinfo(&dsc, idx_subd, &sbinfo);
	if (err < 0) {
		fprintf(stderr, 
			"cmd_bits: get_sbinfo(%d) failed (err = %d)\n",
			idx_subd, err);
		err = -EINVAL;
		goto out_cmd_bits;
	}

	cmd.idx_subd = insn.idx_subd = idx_subd;

	if ((sbinfo->flags & A4L_SUBD_TYPES) != A4L_SUBD_DIO &&
	    (sbinfo->flags & A4L_SUBD_TYPES) != A4L_SUBD_DO) {
		fprintf(stderr, 
			"cmd_bits: selected subdevice is not digital\n");
		err = -EINVAL;
		goto out_cmd_bits;		
	}

	/* Set the data size to read / write */
	scan_size = a4l_sizeof_subd(sbinfo);

	/* Handle little endian case with scan size < 32 */
	if (scan_size == sizeof(uint8_t)) {
		value *= 0x01010101;
	}
	else if (scan_size == sizeof(uint16_t)) {
		value *= 0x00010001;
	}

	/* Configure the polarities */
	for (i = 0; i < scan_size; i++) {
		int mode = (mask & (1 << i)) ? 
			A4L_INSN_CONFIG_DIO_OUTPUT : A4L_INSN_CONFIG_DIO_INPUT;

		err = a4l_config_subd(&dsc, cmd.idx_subd, mode, i);
		if (err < 0) {
			fprintf(stderr, 
				"cmd_bits: configuration of "
				"line %d failed (err=%d)\n", 
				i, err);
			goto out_cmd_bits;
		}
	}

	/* Send the command to the output device */
	err = a4l_snd_command(&dsc, &cmd);
	if (err < 0) {
		fprintf(stderr,
			"cmd_bits: a4l_snd_command failed (err=%d)\n", err);
		goto out_cmd_bits;
	}

	if (verbose != 0)
		printf("cmd_bits: command successfully sent\n");

	/* Perform the write operations */
	for (i=1; i<=100; ++i) { // sschaal: hacked for loop
	  printf("%d\n",i);
	  total = 0;
	do {
		err = a4l_async_write(&dsc, &value, scan_size, A4L_INFINITE);
		if (err < 0) {
			fprintf(stderr, 
				"cmd_bits: a4l_write failed (err=%d)\n", err);
			goto out_cmd_bits;
		}
		
		total += err;

		if (!triggered && total > trigger_threshold) {
			err = a4l_snd_insn(&dsc, &insn);
			if (err < 0) {
				fprintf(stderr, 
					"cmd_bits: triggering failed (err=%d)\n",
					err);
				goto out_cmd_bits;
			}
		}

	} while (err > 0);       	
	} // sschaal end hack for loop

out_cmd_bits:

	/* Free the buffer used as device descriptor */
	if (dsc.sbdata != NULL)
		free(dsc.sbdata);

	/* Release the file descriptor */
	a4l_close(&dsc);

	return err;
}

Re: [Xenomai-core] analogy - experimental branch

[Alexis Berlemont]

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 0xffff 0xffff" 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.

Re: [Xenomai-core] analogy - experimental branch

[Stefan Schaal]

Hi Alexis,

  I did a reboot, ran my modified cmd_bits.c again one time. 

cat /proc/xenomai/irq  reports:

IRQ         CPU0        CPU1        CPU2        CPU3        CPU4        CPU5        CPU6        CPU7
 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 0xffff 0xffff" 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.

Re: [Xenomai-core] analogy - experimental branch

[Alexis Berlemont]

Hi,

Stefan Schaal wrote:
> Hi Alexis,
> 
>   I did a reboot, ran my modified cmd_bits.c again one time. 
> 
> cat /proc/xenomai/irq  reports:
> 
> IRQ         CPU0        CPU1        CPU2        CPU3        CPU4        CPU5        CPU6        CPU7
>  56:           0           0           0           0           0           0           0           0         Analogy device
> 518:           0           1           1           1           1           1           1           1         [IPI]
> 521:      626392      618020      618539      620274      617326      625008      622464      626300         [timer]
> 522:           0           0           0           0           0           0           0           0         [critical sync]
> 546:           0           0           0           0           0           0           0           0         [virtual]
> 

I have not forgotten you. I am still stuck with your bug: The mite
transfers the first 8000 bytes and after does nothing; no interrupt is
generated by the mite so as to finally awake your application. 

It seems like the data retrieved by the mite are not consumed by the
board. Are you sure the digital output lines correspond to what you
configured with cmd_bits ? 

I think the digital output is misconfigured. I am working on it.

> 
> -Stefan
> 
> On Jun 27, 2010, at 3:37, Alexis Berlemont wrote:
> 
> > Hi,
> > 
> > 
> > Stefan Schaal wrote:
> >> Hi Alexis,
> >> 
> >>  thanks so much for the new analogy software. Here are some first observations:
> >> 
> >> 1) cmd_bits.c works fine on our NI6250 board
> >> 
> >> 2) however, a slightly modified version hangs -- I appended my cmd_bits.c to this email. All what I added is a for loop around the a4l_async_write() and a4l_snd_insn() commands, i.e., I wanted to trigger a write repeatedly. Look for the "sschaal" comment in my modified cmd_bits.c .  After 32 iterations, cmd_bits hangs, no error messages in dmesg. Interesting, when I change your "trigger_threshold" variable from 128 to 256, my loop runs for 16 iterations (other changes of the trigger threshold adjust the number of iterations I get in a similar way). Thus, it feels like there is a buffer which does not get reset after a4l_snd_insn() is called -- does this make sense?
> >> 
> > 
> > Could you tell me if the mite triggered an interrupt ? Could you send
> > a dump of cat /proc/xenomai/irq after having made the test program
> > hang ?
> > 
> > Many thanks,
> > 
> >> Best wishes,
> >> 
> >> -Stefan
> >> 
> >> 
> >> On Jun 24, 2010, at 15:43, Alexis Berlemont wrote:
> >> 
> >>> Hi,
> >>> 
> >>> Alexis Berlemont wrote:
> >>>> Hi Stefan,
> >>>> 
> >>>> Stefan Schaal wrote:
> >>>>> Hi Alexis,
> >>>>> 
> >>>>> I was just wondering whether the new "experimental" branch in your git repository is something that can be tried already.
> >>>>> 
> >>>> 
> >>>> No. Not yet. This branch is aimed at temporarily holding the
> >>>> corrections I am trying to do for the cmd_bits issue. It needs quite a
> >>>> lot of work and I have not finished yet. 
> >>>> 
> >>>> If you have a look at the commits in this branch, we will see many
> >>>> "(broken)".
> >>>> 
> >>> 
> >>> I just rebased the experimental branch into the branch analogy. So,
> >>> starting from now, we should be able to properly use cmd_bits with a
> >>> clone of my git repository.
> >>> 
> >>> After having reworked the asynchronous buffer subsystem (and having
> >>> fixed some oops in the NI driver and in the new code), cmd_bits can
> >>> correctly communicate with the DIO subdevice. 
> >>> 
> >>> A command like "./cmd_bits 0xffff 0xffff" works on my
> >>> board. Unfortunately, I have not done the necessary to check the
> >>> digital output lines yet.
> >>> 
> >>> 
> >>>>> Best wishes,
> >>>>> 
> >>>>> -Stefan
> >>>> 
> >>>> -- 
> >>>> Alexis.
> >>> 
> >>> -- 
> >>> Alexis.
> >> 
> >> 
> >> ======================================================= cmd_bits.c ==================================================
> > 
> > 
> > 
> > -- 
> > Alexis.
> 

-- 
Alexis.

Re: [Xenomai-core] analogy - experimental branch

[Stefan Schaal]

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.

Best wishes,

-Stefan


On Jun 30, 2010, at 15:45, Alexis Berlemont wrote:

> Hi,
> 
> Stefan Schaal wrote:
>> Hi Alexis,
>> 
>>  I did a reboot, ran my modified cmd_bits.c again one time. 
>> 
>> cat /proc/xenomai/irq  reports:
>> 
>> IRQ         CPU0        CPU1        CPU2        CPU3        CPU4        CPU5        CPU6        CPU7
>> 56:           0           0           0           0           0           0           0           0         Analogy device
>> 518:           0           1           1           1           1           1           1           1         [IPI]
>> 521:      626392      618020      618539      620274      617326      625008      622464      626300         [timer]
>> 522:           0           0           0           0           0           0           0           0         [critical sync]
>> 546:           0           0           0           0           0           0           0           0         [virtual]
>> 
> 
> I have not forgotten you. I am still stuck with your bug: The mite
> transfers the first 8000 bytes and after does nothing; no interrupt is
> generated by the mite so as to finally awake your application. 
> 
> It seems like the data retrieved by the mite are not consumed by the
> board. Are you sure the digital output lines correspond to what you
> configured with cmd_bits ? 
> 
> I think the digital output is misconfigured. I am working on it.
> 
>> 
>> -Stefan
>> 
>> On Jun 27, 2010, at 3:37, Alexis Berlemont wrote:
>> 
>>> Hi,
>>> 
>>> 
>>> Stefan Schaal wrote:
>>>> Hi Alexis,
>>>> 
>>>> thanks so much for the new analogy software. Here are some first observations:
>>>> 
>>>> 1) cmd_bits.c works fine on our NI6250 board
>>>> 
>>>> 2) however, a slightly modified version hangs -- I appended my cmd_bits.c to this email. All what I added is a for loop around the a4l_async_write() and a4l_snd_insn() commands, i.e., I wanted to trigger a write repeatedly. Look for the "sschaal" comment in my modified cmd_bits.c .  After 32 iterations, cmd_bits hangs, no error messages in dmesg. Interesting, when I change your "trigger_threshold" variable from 128 to 256, my loop runs for 16 iterations (other changes of the trigger threshold adjust the number of iterations I get in a similar way). Thus, it feels like there is a buffer which does not get reset after a4l_snd_insn() is called -- does this make sense?
>>>> 
>>> 
>>> Could you tell me if the mite triggered an interrupt ? Could you send
>>> a dump of cat /proc/xenomai/irq after having made the test program
>>> hang ?
>>> 
>>> Many thanks,
>>> 
>>>> Best wishes,
>>>> 
>>>> -Stefan
>>>> 
>>>> 
>>>> On Jun 24, 2010, at 15:43, Alexis Berlemont wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> Alexis Berlemont wrote:
>>>>>> Hi Stefan,
>>>>>> 
>>>>>> Stefan Schaal wrote:
>>>>>>> Hi Alexis,
>>>>>>> 
>>>>>>> I was just wondering whether the new "experimental" branch in your git repository is something that can be tried already.
>>>>>>> 
>>>>>> 
>>>>>> No. Not yet. This branch is aimed at temporarily holding the
>>>>>> corrections I am trying to do for the cmd_bits issue. It needs quite a
>>>>>> lot of work and I have not finished yet. 
>>>>>> 
>>>>>> If you have a look at the commits in this branch, we will see many
>>>>>> "(broken)".
>>>>>> 
>>>>> 
>>>>> I just rebased the experimental branch into the branch analogy. So,
>>>>> starting from now, we should be able to properly use cmd_bits with a
>>>>> clone of my git repository.
>>>>> 
>>>>> After having reworked the asynchronous buffer subsystem (and having
>>>>> fixed some oops in the NI driver and in the new code), cmd_bits can
>>>>> correctly communicate with the DIO subdevice. 
>>>>> 
>>>>> A command like "./cmd_bits 0xffff 0xffff" works on my
>>>>> board. Unfortunately, I have not done the necessary to check the
>>>>> digital output lines yet.
>>>>> 
>>>>> 
>>>>>>> Best wishes,
>>>>>>> 
>>>>>>> -Stefan
>>>>>> 
>>>>>> -- 
>>>>>> Alexis.
>>>>> 
>>>>> -- 
>>>>> Alexis.
>>>> 
>>>> 
>>>> ======================================================= cmd_bits.c ==================================================
>>> 
>>> 
>>> 
>>> -- 
>>> Alexis.
>> 
> 
> -- 
> Alexis.

Re: [Xenomai-core] analogy - experimental branch

[Alexis Berlemont]

Hi,

Stefan Schaal wrote:
> Hi Alexis,
> 
>   thanks for the feedback. We have 32 bit DIO on subdevice #2, and I am not sure that there is anything special to be configured. I will check again. Feel free to log into our machine with the pwd I indicated to you some time ago. The computer is not used productively.
> 

Sorry for answering late, I was unavailable.

My question was: did you ensure that the digital line were properly
modified after having launched cmd_bits ? 

As I said, the digital output system does not consume the data (now I
am sure). I instrumetented the code and I found out that the mite
copied about 8000 bytes from the RAM and filled the digital output
FIFO. Then, the DO FIFO status register keeps on indicating the FIFO
is full. Nothing happens, the digital output system does not retrieve
data from the FIFO.

I tried to find out why and I had a close look at the driver: I
noticed that no sample clock was configured. The driver only proposes
to use an external signal (from the digital system, so AI/AO clocks,
counters, PFI, etc.) as sample clock. Unfortunately, I do not know
which value corresponds to which clock source.

I had a look a the DAQ documentation: unfortunately the M series
digital system is different (the DAQ-STC document is not valid for
this board). I tried to find the M series developer manual but it is
unavailable according to the NI support. I found a document named
mseries_registermap.doc in: 
http://digital.ni.com/express.nsf/bycode/exyv4w?opendocument

Unfortunately, it does not tell how to configure the sample clock
source (I know which register I have to fill, but I do not know which
value to put so as to use AI clock, digital counters or PFI...)

So, I am kind of stuck. I will proceed on looking for the missing
pieces of information. Please, if anyone have the info (the mapping
between the "CDO_Mode register" values and the sample clock source),
do not hesitate to help us.


> Best wishes,
> 
> -Stefan
> 
> 
> On Jun 30, 2010, at 15:45, Alexis Berlemont wrote:
> 
> > Hi,
> > 
> > Stefan Schaal wrote:
> >> Hi Alexis,
> >> 
> >>  I did a reboot, ran my modified cmd_bits.c again one time. 
> >> 
> >> cat /proc/xenomai/irq  reports:
> >> 
> >> IRQ         CPU0        CPU1        CPU2        CPU3        CPU4        CPU5        CPU6        CPU7
> >> 56:           0           0           0           0           0           0           0           0         Analogy device
> >> 518:           0           1           1           1           1           1           1           1         [IPI]
> >> 521:      626392      618020      618539      620274      617326      625008      622464      626300         [timer]
> >> 522:           0           0           0           0           0           0           0           0         [critical sync]
> >> 546:           0           0           0           0           0           0           0           0         [virtual]
> >> 
> > 
> > I have not forgotten you. I am still stuck with your bug: The mite
> > transfers the first 8000 bytes and after does nothing; no interrupt is
> > generated by the mite so as to finally awake your application. 
> > 
> > It seems like the data retrieved by the mite are not consumed by the
> > board. Are you sure the digital output lines correspond to what you
> > configured with cmd_bits ? 
> > 
> > I think the digital output is misconfigured. I am working on it.
> > 
> >> 
> >> -Stefan
> >> 
> >> On Jun 27, 2010, at 3:37, Alexis Berlemont wrote:
> >> 
> >>> Hi,
> >>> 
> >>> 
> >>> Stefan Schaal wrote:
> >>>> Hi Alexis,
> >>>> 
> >>>> thanks so much for the new analogy software. Here are some first observations:
> >>>> 
> >>>> 1) cmd_bits.c works fine on our NI6250 board
> >>>> 
> >>>> 2) however, a slightly modified version hangs -- I appended my cmd_bits.c to this email. All what I added is a for loop around the a4l_async_write() and a4l_snd_insn() commands, i.e., I wanted to trigger a write repeatedly. Look for the "sschaal" comment in my modified cmd_bits.c .  After 32 iterations, cmd_bits hangs, no error messages in dmesg. Interesting, when I change your "trigger_threshold" variable from 128 to 256, my loop runs for 16 iterations (other changes of the trigger threshold adjust the number of iterations I get in a similar way). Thus, it feels like there is a buffer which does not get reset after a4l_snd_insn() is called -- does this make sense?
> >>>> 
> >>> 
> >>> Could you tell me if the mite triggered an interrupt ? Could you send
> >>> a dump of cat /proc/xenomai/irq after having made the test program
> >>> hang ?
> >>> 
> >>> Many thanks,
> >>> 
> >>>> Best wishes,
> >>>> 
> >>>> -Stefan
> >>>> 
> >>>> 
> >>>> On Jun 24, 2010, at 15:43, Alexis Berlemont wrote:
> >>>> 
> >>>>> Hi,
> >>>>> 
> >>>>> Alexis Berlemont wrote:
> >>>>>> Hi Stefan,
> >>>>>> 
> >>>>>> Stefan Schaal wrote:
> >>>>>>> Hi Alexis,
> >>>>>>> 
> >>>>>>> I was just wondering whether the new "experimental" branch in your git repository is something that can be tried already.
> >>>>>>> 
> >>>>>> 
> >>>>>> No. Not yet. This branch is aimed at temporarily holding the
> >>>>>> corrections I am trying to do for the cmd_bits issue. It needs quite a
> >>>>>> lot of work and I have not finished yet. 
> >>>>>> 
> >>>>>> If you have a look at the commits in this branch, we will see many
> >>>>>> "(broken)".
> >>>>>> 
> >>>>> 
> >>>>> I just rebased the experimental branch into the branch analogy. So,
> >>>>> starting from now, we should be able to properly use cmd_bits with a
> >>>>> clone of my git repository.
> >>>>> 
> >>>>> After having reworked the asynchronous buffer subsystem (and having
> >>>>> fixed some oops in the NI driver and in the new code), cmd_bits can
> >>>>> correctly communicate with the DIO subdevice. 
> >>>>> 
> >>>>> A command like "./cmd_bits 0xffff 0xffff" works on my
> >>>>> board. Unfortunately, I have not done the necessary to check the
> >>>>> digital output lines yet.
> >>>>> 
> >>>>> 
> >>>>>>> Best wishes,
> >>>>>>> 
> >>>>>>> -Stefan
> >>>>>> 
> >>>>>> -- 
> >>>>>> Alexis.
> >>>>> 
> >>>>> -- 
> >>>>> Alexis.
> >>>> 
> >>>> 
> >>>> ======================================================= cmd_bits.c ==================================================
> >>> 
> >>> 
> >>> 
> >>> -- 
> >>> Alexis.
> >> 
> > 
> > -- 
> > Alexis.
> 

-- 
Alexis.

Re: [Xenomai-core] analogy - experimental branch

[Alexis Berlemont]

Hi,

Alexis Berlemont wrote:
> Hi,
> 
> Stefan Schaal wrote:
> > Hi Alexis,
> > 
> >   thanks for the feedback. We have 32 bit DIO on subdevice #2, and I am not sure that there is anything special to be configured. I will check again. Feel free to log into our machine with the pwd I indicated to you some time ago. The computer is not used productively.
> > 
> 
> Sorry for answering late, I was unavailable.
> 
> My question was: did you ensure that the digital line were properly
> modified after having launched cmd_bits ? 
> 
> As I said, the digital output system does not consume the data (now I
> am sure). I instrumetented the code and I found out that the mite
> copied about 8000 bytes from the RAM and filled the digital output
> FIFO. Then, the DO FIFO status register keeps on indicating the FIFO
> is full. Nothing happens, the digital output system does not retrieve
> data from the FIFO.
> 
> I tried to find out why and I had a close look at the driver: I
> noticed that no sample clock was configured. The driver only proposes
> to use an external signal (from the digital system, so AI/AO clocks,
> counters, PFI, etc.) as sample clock. Unfortunately, I do not know
> which value corresponds to which clock source.
> 
> I had a look a the DAQ documentation: unfortunately the M series
> digital system is different (the DAQ-STC document is not valid for
> this board). I tried to find the M series developer manual but it is
> unavailable according to the NI support. I found a document named
> mseries_registermap.doc in: 
> http://digital.ni.com/express.nsf/bycode/exyv4w?opendocument
> 
> Unfortunately, it does not tell how to configure the sample clock
> source (I know which register I have to fill, but I do not know which
> value to put so as to use AI clock, digital counters or PFI...)
> 
> So, I am kind of stuck. I will proceed on looking for the missing
> pieces of information. Please, if anyone have the info (the mapping
> between the "CDO_Mode register" values and the sample clock source),
> do not hesitate to help us.
> 

Argh, I found it. I did not see an item in the url displayed above.


Here is an enum found in:
ftp://ftp.ni.com/support/daq/mhddk/examples/nimseries.zip

      // Field Accessors (Compile-time selectable)
      typedef enum {
         kCDO_Update_Source_SelectGround            = 0,
         kCDO_Update_Source_SelectPFI0              = 1,
         kCDO_Update_Source_SelectPFI1              = 2,
         kCDO_Update_Source_SelectPFI2              = 3,
         kCDO_Update_Source_SelectPFI3              = 4,
         kCDO_Update_Source_SelectPFI4              = 5,
         kCDO_Update_Source_SelectPFI5              = 6,
         kCDO_Update_Source_SelectPFI6              = 7,
         kCDO_Update_Source_SelectPFI7              = 8,
         kCDO_Update_Source_SelectPFI8              = 9,
         kCDO_Update_Source_SelectPFI9              = 10,
         kCDO_Update_Source_SelectRTSI0             = 11,
         kCDO_Update_Source_SelectRTSI1             = 12,
         kCDO_Update_Source_SelectRTSI2             = 13,
         kCDO_Update_Source_SelectRTSI3             = 14,
         kCDO_Update_Source_SelectRTSI4             = 15,
         kCDO_Update_Source_SelectRTSI5             = 16,
         kCDO_Update_Source_SelectRTSI6             = 17,
         kCDO_Update_Source_SelectAI_Start          = 18,
         kCDO_Update_Source_SelectAI_Convert        = 19,
         kCDO_Update_Source_SelectPXI_Star_Trigger  = 20,
         kCDO_Update_Source_SelectPFI10             = 21,
         kCDO_Update_Source_SelectPFI11             = 22,
         kCDO_Update_Source_SelectPFI12             = 23,
         kCDO_Update_Source_SelectPFI13             = 24,
         kCDO_Update_Source_SelectPFI14             = 25,
         kCDO_Update_Source_SelectPFI15             = 26,
         kCDO_Update_Source_SelectRTSI7             = 27,
         kCDO_Update_Source_SelectG0_Out            = 28,
         kCDO_Update_Source_SelectG1_Out            = 29,
         kCDO_Update_Source_SelectAnalog_Trigger    = 30,
         kCDO_Update_Source_SelectAO_Update         = 31,
         kCDO_Update_Source_SelectFreq_Out          = 32,
         kCDO_Update_Source_SelectDIO_Change_Detect_Irq       = 33,
      } tCDO_Update_Source_Select;

So, Stefan, here is a quick solution:

if you have access to your board you can choose one of these signals
(in which a regular pulse is occuring) and you can modify accordingly
the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c. 

> 
> > Best wishes,
> > 
> > -Stefan
> > 
> > 
> > On Jun 30, 2010, at 15:45, Alexis Berlemont wrote:
> > 
> > > Hi,
> > > 
> > > Stefan Schaal wrote:
> > >> Hi Alexis,
> > >> 
> > >>  I did a reboot, ran my modified cmd_bits.c again one time. 
> > >> 
> > >> cat /proc/xenomai/irq  reports:
> > >> 
> > >> IRQ         CPU0        CPU1        CPU2        CPU3        CPU4        CPU5        CPU6        CPU7
> > >> 56:           0           0           0           0           0           0           0           0         Analogy device
> > >> 518:           0           1           1           1           1           1           1           1         [IPI]
> > >> 521:      626392      618020      618539      620274      617326      625008      622464      626300         [timer]
> > >> 522:           0           0           0           0           0           0           0           0         [critical sync]
> > >> 546:           0           0           0           0           0           0           0           0         [virtual]
> > >> 
> > > 
> > > I have not forgotten you. I am still stuck with your bug: The mite
> > > transfers the first 8000 bytes and after does nothing; no interrupt is
> > > generated by the mite so as to finally awake your application. 
> > > 
> > > It seems like the data retrieved by the mite are not consumed by the
> > > board. Are you sure the digital output lines correspond to what you
> > > configured with cmd_bits ? 
> > > 
> > > I think the digital output is misconfigured. I am working on it.
> > > 
> > >> 
> > >> -Stefan
> > >> 
> > >> On Jun 27, 2010, at 3:37, Alexis Berlemont wrote:
> > >> 
> > >>> Hi,
> > >>> 
> > >>> 
> > >>> Stefan Schaal wrote:
> > >>>> Hi Alexis,
> > >>>> 
> > >>>> thanks so much for the new analogy software. Here are some first observations:
> > >>>> 
> > >>>> 1) cmd_bits.c works fine on our NI6250 board
> > >>>> 
> > >>>> 2) however, a slightly modified version hangs -- I appended my cmd_bits.c to this email. All what I added is a for loop around the a4l_async_write() and a4l_snd_insn() commands, i.e., I wanted to trigger a write repeatedly. Look for the "sschaal" comment in my modified cmd_bits.c .  After 32 iterations, cmd_bits hangs, no error messages in dmesg. Interesting, when I change your "trigger_threshold" variable from 128 to 256, my loop runs for 16 iterations (other changes of the trigger threshold adjust the number of iterations I get in a similar way). Thus, it feels like there is a buffer which does not get reset after a4l_snd_insn() is called -- does this make sense?
> > >>>> 
> > >>> 
> > >>> Could you tell me if the mite triggered an interrupt ? Could you send
> > >>> a dump of cat /proc/xenomai/irq after having made the test program
> > >>> hang ?
> > >>> 
> > >>> Many thanks,
> > >>> 
> > >>>> Best wishes,
> > >>>> 
> > >>>> -Stefan
> > >>>> 
> > >>>> 
> > >>>> On Jun 24, 2010, at 15:43, Alexis Berlemont wrote:
> > >>>> 
> > >>>>> Hi,
> > >>>>> 
> > >>>>> Alexis Berlemont wrote:
> > >>>>>> Hi Stefan,
> > >>>>>> 
> > >>>>>> Stefan Schaal wrote:
> > >>>>>>> Hi Alexis,
> > >>>>>>> 
> > >>>>>>> I was just wondering whether the new "experimental" branch in your git repository is something that can be tried already.
> > >>>>>>> 
> > >>>>>> 
> > >>>>>> No. Not yet. This branch is aimed at temporarily holding the
> > >>>>>> corrections I am trying to do for the cmd_bits issue. It needs quite a
> > >>>>>> lot of work and I have not finished yet. 
> > >>>>>> 
> > >>>>>> If you have a look at the commits in this branch, we will see many
> > >>>>>> "(broken)".
> > >>>>>> 
> > >>>>> 
> > >>>>> I just rebased the experimental branch into the branch analogy. So,
> > >>>>> starting from now, we should be able to properly use cmd_bits with a
> > >>>>> clone of my git repository.
> > >>>>> 
> > >>>>> After having reworked the asynchronous buffer subsystem (and having
> > >>>>> fixed some oops in the NI driver and in the new code), cmd_bits can
> > >>>>> correctly communicate with the DIO subdevice. 
> > >>>>> 
> > >>>>> A command like "./cmd_bits 0xffff 0xffff" works on my
> > >>>>> board. Unfortunately, I have not done the necessary to check the
> > >>>>> digital output lines yet.
> > >>>>> 
> > >>>>> 
> > >>>>>>> Best wishes,
> > >>>>>>> 
> > >>>>>>> -Stefan
> > >>>>>> 
> > >>>>>> -- 
> > >>>>>> Alexis.
> > >>>>> 
> > >>>>> -- 
> > >>>>> Alexis.
> > >>>> 
> > >>>> 
> > >>>> ======================================================= cmd_bits.c ==================================================
> > >>> 
> > >>> 
> > >>> 
> > >>> -- 
> > >>> Alexis.
> > >> 
> > > 
> > > -- 
> > > Alexis.
> > 
> 
> -- 
> Alexis.

-- 
Alexis.

Re: [Xenomai-core] analogy - experimental branch

[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,
>         kCDO_Update_Source_SelectPFI14             = 25,
>         kCDO_Update_Source_SelectPFI15             = 26,
>         kCDO_Update_Source_SelectRTSI7             = 27,
>         kCDO_Update_Source_SelectG0_Out            = 28,
>         kCDO_Update_Source_SelectG1_Out            = 29,
>         kCDO_Update_Source_SelectAnalog_Trigger    = 30,
>         kCDO_Update_Source_SelectAO_Update         = 31,
>         kCDO_Update_Source_SelectFreq_Out          = 32,
>         kCDO_Update_Source_SelectDIO_Change_Detect_Irq       = 33,
>      } tCDO_Update_Source_Select;
> 
> So, Stefan, here is a quick solution:
> 
> if you have access to your board you can choose one of these signals
> (in which a regular pulse is occuring) and you can modify accordingly
> the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c. 
> 
>> 
>>> Best wishes,
>>> 
>>> -Stefan
>>> 
>>> 
>>> On Jun 30, 2010, at 15:45, Alexis Berlemont wrote:
>>> 
>>>> Hi,
>>>> 
>>>> Stefan Schaal wrote:
>>>>> Hi Alexis,
>>>>> 
>>>>> I did a reboot, ran my modified cmd_bits.c again one time. 
>>>>> 
>>>>> cat /proc/xenomai/irq  reports:
>>>>> 
>>>>> IRQ         CPU0        CPU1        CPU2        CPU3        CPU4        CPU5        CPU6        CPU7
>>>>> 56:           0           0           0           0           0           0           0           0         Analogy device
>>>>> 518:           0           1           1           1           1           1           1           1         [IPI]
>>>>> 521:      626392      618020      618539      620274      617326      625008      622464      626300         [timer]
>>>>> 522:           0           0           0           0           0           0           0           0         [critical sync]
>>>>> 546:           0           0           0           0           0           0           0           0         [virtual]
>>>>> 
>>>> 
>>>> I have not forgotten you. I am still stuck with your bug: The mite
>>>> transfers the first 8000 bytes and after does nothing; no interrupt is
>>>> generated by the mite so as to finally awake your application. 
>>>> 
>>>> It seems like the data retrieved by the mite are not consumed by the
>>>> board. Are you sure the digital output lines correspond to what you
>>>> configured with cmd_bits ? 
>>>> 
>>>> I think the digital output is misconfigured. I am working on it.
>>>> 
>>>>> 
>>>>> -Stefan
>>>>> 
>>>>> On Jun 27, 2010, at 3:37, Alexis Berlemont wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> 
>>>>>> Stefan Schaal wrote:
>>>>>>> Hi Alexis,
>>>>>>> 
>>>>>>> thanks so much for the new analogy software. Here are some first observations:
>>>>>>> 
>>>>>>> 1) cmd_bits.c works fine on our NI6250 board
>>>>>>> 
>>>>>>> 2) however, a slightly modified version hangs -- I appended my cmd_bits.c to this email. All what I added is a for loop around the a4l_async_write() and a4l_snd_insn() commands, i.e., I wanted to trigger a write repeatedly. Look for the "sschaal" comment in my modified cmd_bits.c .  After 32 iterations, cmd_bits hangs, no error messages in dmesg. Interesting, when I change your "trigger_threshold" variable from 128 to 256, my loop runs for 16 iterations (other changes of the trigger threshold adjust the number of iterations I get in a similar way). Thus, it feels like there is a buffer which does not get reset after a4l_snd_insn() is called -- does this make sense?
>>>>>>> 
>>>>>> 
>>>>>> Could you tell me if the mite triggered an interrupt ? Could you send
>>>>>> a dump of cat /proc/xenomai/irq after having made the test program
>>>>>> hang ?
>>>>>> 
>>>>>> Many thanks,
>>>>>> 
>>>>>>> Best wishes,
>>>>>>> 
>>>>>>> -Stefan
>>>>>>> 
>>>>>>> 
>>>>>>> On Jun 24, 2010, at 15:43, Alexis Berlemont wrote:
>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Alexis Berlemont wrote:
>>>>>>>>> Hi Stefan,
>>>>>>>>> 
>>>>>>>>> Stefan Schaal wrote:
>>>>>>>>>> Hi Alexis,
>>>>>>>>>> 
>>>>>>>>>> I was just wondering whether the new "experimental" branch in your git repository is something that can be tried already.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> No. Not yet. This branch is aimed at temporarily holding the
>>>>>>>>> corrections I am trying to do for the cmd_bits issue. It needs quite a
>>>>>>>>> lot of work and I have not finished yet. 
>>>>>>>>> 
>>>>>>>>> If you have a look at the commits in this branch, we will see many
>>>>>>>>> "(broken)".
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> I just rebased the experimental branch into the branch analogy. So,
>>>>>>>> starting from now, we should be able to properly use cmd_bits with a
>>>>>>>> clone of my git repository.
>>>>>>>> 
>>>>>>>> After having reworked the asynchronous buffer subsystem (and having
>>>>>>>> fixed some oops in the NI driver and in the new code), cmd_bits can
>>>>>>>> correctly communicate with the DIO subdevice. 
>>>>>>>> 
>>>>>>>> A command like "./cmd_bits 0xffff 0xffff" works on my
>>>>>>>> board. Unfortunately, I have not done the necessary to check the
>>>>>>>> digital output lines yet.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>> Best wishes,
>>>>>>>>>> 
>>>>>>>>>> -Stefan
>>>>>>>>> 
>>>>>>>>> -- 
>>>>>>>>> Alexis.
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> Alexis.
>>>>>>> 
>>>>>>> 
>>>>>>> ======================================================= cmd_bits.c ==================================================
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Alexis.
>>>>> 
>>>> 
>>>> -- 
>>>> Alexis.
>>> 
>> 
>> -- 
>> Alexis.
> 
> -- 
> Alexis.

Re: [Xenomai-core] analogy - experimental branch

[Alexis Berlemont]

Stefan Schaal wrote:
> Hi Alexis,
> 
>   I conceptually understand what you are telling us, but I am bit confused how to implement your advice:
> 
> > So, Stefan, here is a quick solution:
> > 
> > if you have access to your board you can choose one of these signals
> > (in which a regular pulse is occuring) and you can modify accordingly
> > the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c. 
> 
> The data structures in question are:
> 
> /* The command to send by default */
> a4l_cmd_t cmd = {
> 	.idx_subd = -1,
> 	.flags = 0,
> 	.start_src = TRIG_INT,
> 	.start_arg = 0,
> 	.scan_begin_src = TRIG_EXT,
> 	.scan_begin_arg = 0, /* in ns */
> 	.convert_src = TRIG_NOW,
> 	.convert_arg = 0, /* in ns */
> 	.scan_end_src = TRIG_COUNT,
> 	.scan_end_arg = 4,
> 	.stop_src = TRIG_NONE,
> 	.stop_arg = 0,
> 	.nb_chan = 4,
> 	.chan_descs = chans,
> };
> 
> a4l_insn_t insn = {
> 	.type = A4L_INSN_INTTRIG,
> 	.idx_subd = -1,
> 	.data_size = 0,
> };
> 
> 
> Thus, I assume you mean that
> 
> scan_begin_src = TRIG_EXT
> 
> should be modified to one of the enum items below? Are all these
> timers automatically running, or do they need to be configured, too?
> Sorry, I am a bit at a loss how to proceed.

Sorry for the delay.

I was not clear enough. In fact, scan_begin_arg should be
modified. scan_begin_src indicates the type of trigger and
scan_begin_arg gives an associated argument. In our case, it is the
signal number. Sorry for the comment (/* in ns */) which is an
inappropriate copy-paste (as a matter of fact, it is the whole command
interface which is unsuitable but that's another topic).

> 
> Best wishes,
> 
> -Stefan
> 
> 
> On Jul 5, 2010, at 15:02, Alexis Berlemont wrote:
> 
> > Hi,
> > 
> > Alexis Berlemont wrote:
> >> Hi,
> >> 
> >> Stefan Schaal wrote:
> >>> Hi Alexis,
> >>> 
> >>>  thanks for the feedback. We have 32 bit DIO on subdevice #2, and I am not sure that there is anything special to be configured. I will check again. Feel free to log into our machine with the pwd I indicated to you some time ago. The computer is not used productively.
> >>> 
> >> 
> >> Sorry for answering late, I was unavailable.
> >> 
> >> My question was: did you ensure that the digital line were properly
> >> modified after having launched cmd_bits ? 
> >> 
> >> As I said, the digital output system does not consume the data (now I
> >> am sure). I instrumetented the code and I found out that the mite
> >> copied about 8000 bytes from the RAM and filled the digital output
> >> FIFO. Then, the DO FIFO status register keeps on indicating the FIFO
> >> is full. Nothing happens, the digital output system does not retrieve
> >> data from the FIFO.
> >> 
> >> I tried to find out why and I had a close look at the driver: I
> >> noticed that no sample clock was configured. The driver only proposes
> >> to use an external signal (from the digital system, so AI/AO clocks,
> >> counters, PFI, etc.) as sample clock. Unfortunately, I do not know
> >> which value corresponds to which clock source.
> >> 
> >> I had a look a the DAQ documentation: unfortunately the M series
> >> digital system is different (the DAQ-STC document is not valid for
> >> this board). I tried to find the M series developer manual but it is
> >> unavailable according to the NI support. I found a document named
> >> mseries_registermap.doc in: 
> >> http://digital.ni.com/express.nsf/bycode/exyv4w?opendocument
> >> 
> >> Unfortunately, it does not tell how to configure the sample clock
> >> source (I know which register I have to fill, but I do not know which
> >> value to put so as to use AI clock, digital counters or PFI...)
> >> 
> >> So, I am kind of stuck. I will proceed on looking for the missing
> >> pieces of information. Please, if anyone have the info (the mapping
> >> between the "CDO_Mode register" values and the sample clock source),
> >> do not hesitate to help us.
> >> 
> > 
> > Argh, I found it. I did not see an item in the url displayed above.
> > 
> > 
> > Here is an enum found in:
> > ftp://ftp.ni.com/support/daq/mhddk/examples/nimseries.zip
> > 
> >      // Field Accessors (Compile-time selectable)
> >      typedef enum {
> >         kCDO_Update_Source_SelectGround            = 0,
> >         kCDO_Update_Source_SelectPFI0              = 1,
> >         kCDO_Update_Source_SelectPFI1              = 2,
> >         kCDO_Update_Source_SelectPFI2              = 3,
> >         kCDO_Update_Source_SelectPFI3              = 4,
> >         kCDO_Update_Source_SelectPFI4              = 5,
> >         kCDO_Update_Source_SelectPFI5              = 6,
> >         kCDO_Update_Source_SelectPFI6              = 7,
> >         kCDO_Update_Source_SelectPFI7              = 8,
> >         kCDO_Update_Source_SelectPFI8              = 9,
> >         kCDO_Update_Source_SelectPFI9              = 10,
> >         kCDO_Update_Source_SelectRTSI0             = 11,
> >         kCDO_Update_Source_SelectRTSI1             = 12,
> >         kCDO_Update_Source_SelectRTSI2             = 13,
> >         kCDO_Update_Source_SelectRTSI3             = 14,
> >         kCDO_Update_Source_SelectRTSI4             = 15,
> >         kCDO_Update_Source_SelectRTSI5             = 16,
> >         kCDO_Update_Source_SelectRTSI6             = 17,
> >         kCDO_Update_Source_SelectAI_Start          = 18,
> >         kCDO_Update_Source_SelectAI_Convert        = 19,
> >         kCDO_Update_Source_SelectPXI_Star_Trigger  = 20,
> >         kCDO_Update_Source_SelectPFI10             = 21,
> >         kCDO_Update_Source_SelectPFI11             = 22,
> >         kCDO_Update_Source_SelectPFI12             = 23,
> >         kCDO_Update_Source_SelectPFI13             = 24,
> >         kCDO_Update_Source_SelectPFI14             = 25,
> >         kCDO_Update_Source_SelectPFI15             = 26,
> >         kCDO_Update_Source_SelectRTSI7             = 27,
> >         kCDO_Update_Source_SelectG0_Out            = 28,
> >         kCDO_Update_Source_SelectG1_Out            = 29,
> >         kCDO_Update_Source_SelectAnalog_Trigger    = 30,
> >         kCDO_Update_Source_SelectAO_Update         = 31,
> >         kCDO_Update_Source_SelectFreq_Out          = 32,
> >         kCDO_Update_Source_SelectDIO_Change_Detect_Irq       = 33,
> >      } tCDO_Update_Source_Select;
> > 
> > So, Stefan, here is a quick solution:
> > 
> > if you have access to your board you can choose one of these signals
> > (in which a regular pulse is occuring) and you can modify accordingly
> > the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c. 
> > 
> >> 
> >>> Best wishes,
> >>> 
> >>> -Stefan
> >>> 
> >>> 
> >>> On Jun 30, 2010, at 15:45, Alexis Berlemont wrote:
> >>> 
> >>>> Hi,
> >>>> 
> >>>> Stefan Schaal wrote:
> >>>>> Hi Alexis,
> >>>>> 
> >>>>> I did a reboot, ran my modified cmd_bits.c again one time. 
> >>>>> 
> >>>>> cat /proc/xenomai/irq  reports:
> >>>>> 
> >>>>> IRQ         CPU0        CPU1        CPU2        CPU3        CPU4        CPU5        CPU6        CPU7
> >>>>> 56:           0           0           0           0           0           0           0           0         Analogy device
> >>>>> 518:           0           1           1           1           1           1           1           1         [IPI]
> >>>>> 521:      626392      618020      618539      620274      617326      625008      622464      626300         [timer]
> >>>>> 522:           0           0           0           0           0           0           0           0         [critical sync]
> >>>>> 546:           0           0           0           0           0           0           0           0         [virtual]
> >>>>> 
> >>>> 
> >>>> I have not forgotten you. I am still stuck with your bug: The mite
> >>>> transfers the first 8000 bytes and after does nothing; no interrupt is
> >>>> generated by the mite so as to finally awake your application. 
> >>>> 
> >>>> It seems like the data retrieved by the mite are not consumed by the
> >>>> board. Are you sure the digital output lines correspond to what you
> >>>> configured with cmd_bits ? 
> >>>> 
> >>>> I think the digital output is misconfigured. I am working on it.
> >>>> 
> >>>>> 
> >>>>> -Stefan
> >>>>> 
> >>>>> On Jun 27, 2010, at 3:37, Alexis Berlemont wrote:
> >>>>> 
> >>>>>> Hi,
> >>>>>> 
> >>>>>> 
> >>>>>> Stefan Schaal wrote:
> >>>>>>> Hi Alexis,
> >>>>>>> 
> >>>>>>> thanks so much for the new analogy software. Here are some first observations:
> >>>>>>> 
> >>>>>>> 1) cmd_bits.c works fine on our NI6250 board
> >>>>>>> 
> >>>>>>> 2) however, a slightly modified version hangs -- I appended my cmd_bits.c to this email. All what I added is a for loop around the a4l_async_write() and a4l_snd_insn() commands, i.e., I wanted to trigger a write repeatedly. Look for the "sschaal" comment in my modified cmd_bits.c .  After 32 iterations, cmd_bits hangs, no error messages in dmesg. Interesting, when I change your "trigger_threshold" variable from 128 to 256, my loop runs for 16 iterations (other changes of the trigger threshold adjust the number of iterations I get in a similar way). Thus, it feels like there is a buffer which does not get reset after a4l_snd_insn() is called -- does this make sense?
> >>>>>>> 
> >>>>>> 
> >>>>>> Could you tell me if the mite triggered an interrupt ? Could you send
> >>>>>> a dump of cat /proc/xenomai/irq after having made the test program
> >>>>>> hang ?
> >>>>>> 
> >>>>>> Many thanks,
> >>>>>> 
> >>>>>>> Best wishes,
> >>>>>>> 
> >>>>>>> -Stefan
> >>>>>>> 
> >>>>>>> 
> >>>>>>> On Jun 24, 2010, at 15:43, Alexis Berlemont wrote:
> >>>>>>> 
> >>>>>>>> Hi,
> >>>>>>>> 
> >>>>>>>> Alexis Berlemont wrote:
> >>>>>>>>> Hi Stefan,
> >>>>>>>>> 
> >>>>>>>>> Stefan Schaal wrote:
> >>>>>>>>>> Hi Alexis,
> >>>>>>>>>> 
> >>>>>>>>>> I was just wondering whether the new "experimental" branch in your git repository is something that can be tried already.
> >>>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> No. Not yet. This branch is aimed at temporarily holding the
> >>>>>>>>> corrections I am trying to do for the cmd_bits issue. It needs quite a
> >>>>>>>>> lot of work and I have not finished yet. 
> >>>>>>>>> 
> >>>>>>>>> If you have a look at the commits in this branch, we will see many
> >>>>>>>>> "(broken)".
> >>>>>>>>> 
> >>>>>>>> 
> >>>>>>>> I just rebased the experimental branch into the branch analogy. So,
> >>>>>>>> starting from now, we should be able to properly use cmd_bits with a
> >>>>>>>> clone of my git repository.
> >>>>>>>> 
> >>>>>>>> After having reworked the asynchronous buffer subsystem (and having
> >>>>>>>> fixed some oops in the NI driver and in the new code), cmd_bits can
> >>>>>>>> correctly communicate with the DIO subdevice. 
> >>>>>>>> 
> >>>>>>>> A command like "./cmd_bits 0xffff 0xffff" works on my
> >>>>>>>> board. Unfortunately, I have not done the necessary to check the
> >>>>>>>> digital output lines yet.
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>>>> Best wishes,
> >>>>>>>>>> 
> >>>>>>>>>> -Stefan
> >>>>>>>>> 
> >>>>>>>>> -- 
> >>>>>>>>> Alexis.
> >>>>>>>> 
> >>>>>>>> -- 
> >>>>>>>> Alexis.
> >>>>>>> 
> >>>>>>> 
> >>>>>>> ======================================================= cmd_bits.c ==================================================
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> -- 
> >>>>>> Alexis.
> >>>>> 
> >>>> 
> >>>> -- 
> >>>> Alexis.
> >>> 
> >> 
> >> -- 
> >> Alexis.
> > 
> > -- 
> > Alexis.
> 

-- 
Alexis.

Re: [Xenomai-core] analogy - experimental branch

[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,
>>>        kCDO_Update_Source_SelectPFI7              = 8,
>>>        kCDO_Update_Source_SelectPFI8              = 9,
>>>        kCDO_Update_Source_SelectPFI9              = 10,
>>>        kCDO_Update_Source_SelectRTSI0             = 11,
>>>        kCDO_Update_Source_SelectRTSI1             = 12,
>>>        kCDO_Update_Source_SelectRTSI2             = 13,
>>>        kCDO_Update_Source_SelectRTSI3             = 14,
>>>        kCDO_Update_Source_SelectRTSI4             = 15,
>>>        kCDO_Update_Source_SelectRTSI5             = 16,
>>>        kCDO_Update_Source_SelectRTSI6             = 17,
>>>        kCDO_Update_Source_SelectAI_Start          = 18,
>>>        kCDO_Update_Source_SelectAI_Convert        = 19,
>>>        kCDO_Update_Source_SelectPXI_Star_Trigger  = 20,
>>>        kCDO_Update_Source_SelectPFI10             = 21,
>>>        kCDO_Update_Source_SelectPFI11             = 22,
>>>        kCDO_Update_Source_SelectPFI12             = 23,
>>>        kCDO_Update_Source_SelectPFI13             = 24,
>>>        kCDO_Update_Source_SelectPFI14             = 25,
>>>        kCDO_Update_Source_SelectPFI15             = 26,
>>>        kCDO_Update_Source_SelectRTSI7             = 27,
>>>        kCDO_Update_Source_SelectG0_Out            = 28,
>>>        kCDO_Update_Source_SelectG1_Out            = 29,
>>>        kCDO_Update_Source_SelectAnalog_Trigger    = 30,
>>>        kCDO_Update_Source_SelectAO_Update         = 31,
>>>        kCDO_Update_Source_SelectFreq_Out          = 32,
>>>        kCDO_Update_Source_SelectDIO_Change_Detect_Irq       = 33,
>>>     } tCDO_Update_Source_Select;
>>> 
>>> So, Stefan, here is a quick solution:
>>> 
>>> if you have access to your board you can choose one of these signals
>>> (in which a regular pulse is occuring) and you can modify accordingly
>>> the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c. 
>>> 
>>>> 
>>>>> Best wishes,
>>>>> 
>>>>> -Stefan
>>>>> 
>>>>> 
>>>>> On Jun 30, 2010, at 15:45, Alexis Berlemont wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Stefan Schaal wrote:
>>>>>>> Hi Alexis,
>>>>>>> 
>>>>>>> I did a reboot, ran my modified cmd_bits.c again one time. 
>>>>>>> 
>>>>>>> cat /proc/xenomai/irq  reports:
>>>>>>> 
>>>>>>> IRQ         CPU0        CPU1        CPU2        CPU3        CPU4        CPU5        CPU6        CPU7
>>>>>>> 56:           0           0           0           0           0           0           0           0         Analogy device
>>>>>>> 518:           0           1           1           1           1           1           1           1         [IPI]
>>>>>>> 521:      626392      618020      618539      620274      617326      625008      622464      626300         [timer]
>>>>>>> 522:           0           0           0           0           0           0           0           0         [critical sync]
>>>>>>> 546:           0           0           0           0           0           0           0           0         [virtual]
>>>>>>> 
>>>>>> 
>>>>>> I have not forgotten you. I am still stuck with your bug: The mite
>>>>>> transfers the first 8000 bytes and after does nothing; no interrupt is
>>>>>> generated by the mite so as to finally awake your application. 
>>>>>> 
>>>>>> It seems like the data retrieved by the mite are not consumed by the
>>>>>> board. Are you sure the digital output lines correspond to what you
>>>>>> configured with cmd_bits ? 
>>>>>> 
>>>>>> I think the digital output is misconfigured. I am working on it.
>>>>>> 
>>>>>>> 
>>>>>>> -Stefan
>>>>>>> 
>>>>>>> On Jun 27, 2010, at 3:37, Alexis Berlemont wrote:
>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Stefan Schaal wrote:
>>>>>>>>> Hi Alexis,
>>>>>>>>> 
>>>>>>>>> thanks so much for the new analogy software. Here are some first observations:
>>>>>>>>> 
>>>>>>>>> 1) cmd_bits.c works fine on our NI6250 board
>>>>>>>>> 
>>>>>>>>> 2) however, a slightly modified version hangs -- I appended my cmd_bits.c to this email. All what I added is a for loop around the a4l_async_write() and a4l_snd_insn() commands, i.e., I wanted to trigger a write repeatedly. Look for the "sschaal" comment in my modified cmd_bits.c .  After 32 iterations, cmd_bits hangs, no error messages in dmesg. Interesting, when I change your "trigger_threshold" variable from 128 to 256, my loop runs for 16 iterations (other changes of the trigger threshold adjust the number of iterations I get in a similar way). Thus, it feels like there is a buffer which does not get reset after a4l_snd_insn() is called -- does this make sense?
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> Could you tell me if the mite triggered an interrupt ? Could you send
>>>>>>>> a dump of cat /proc/xenomai/irq after having made the test program
>>>>>>>> hang ?
>>>>>>>> 
>>>>>>>> Many thanks,
>>>>>>>> 
>>>>>>>>> Best wishes,
>>>>>>>>> 
>>>>>>>>> -Stefan
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Jun 24, 2010, at 15:43, Alexis Berlemont wrote:
>>>>>>>>> 
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> Alexis Berlemont wrote:
>>>>>>>>>>> Hi Stefan,
>>>>>>>>>>> 
>>>>>>>>>>> Stefan Schaal wrote:
>>>>>>>>>>>> Hi Alexis,
>>>>>>>>>>>> 
>>>>>>>>>>>> I was just wondering whether the new "experimental" branch in your git repository is something that can be tried already.
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> No. Not yet. This branch is aimed at temporarily holding the
>>>>>>>>>>> corrections I am trying to do for the cmd_bits issue. It needs quite a
>>>>>>>>>>> lot of work and I have not finished yet. 
>>>>>>>>>>> 
>>>>>>>>>>> If you have a look at the commits in this branch, we will see many
>>>>>>>>>>> "(broken)".
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> I just rebased the experimental branch into the branch analogy. So,
>>>>>>>>>> starting from now, we should be able to properly use cmd_bits with a
>>>>>>>>>> clone of my git repository.
>>>>>>>>>> 
>>>>>>>>>> After having reworked the asynchronous buffer subsystem (and having
>>>>>>>>>> fixed some oops in the NI driver and in the new code), cmd_bits can
>>>>>>>>>> correctly communicate with the DIO subdevice. 
>>>>>>>>>> 
>>>>>>>>>> A command like "./cmd_bits 0xffff 0xffff" works on my
>>>>>>>>>> board. Unfortunately, I have not done the necessary to check the
>>>>>>>>>> digital output lines yet.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>>> Best wishes,
>>>>>>>>>>>> 
>>>>>>>>>>>> -Stefan
>>>>>>>>>>> 
>>>>>>>>>>> -- 
>>>>>>>>>>> Alexis.
>>>>>>>>>> 
>>>>>>>>>> -- 
>>>>>>>>>> Alexis.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ======================================================= cmd_bits.c ==================================================
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> Alexis.
>>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Alexis.
>>>>> 
>>>> 
>>>> -- 
>>>> Alexis.
>>> 
>>> -- 
>>> Alexis.
>> 
> 
> -- 
> Alexis.

Re: [Xenomai-core] analogy - experimental branch

[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 above.
>>>> 
>>>> 
>>>> Here is an enum found in:
>>>> ftp://ftp.ni.com/support/daq/mhddk/examples/nimseries.zip
>>>> 
>>>>    // Field Accessors (Compile-time selectable)
>>>>    typedef enum {
>>>>       kCDO_Update_Source_SelectGround            = 0,
>>>>       kCDO_Update_Source_SelectPFI0              = 1,
>>>>       kCDO_Update_Source_SelectPFI1              = 2,
>>>>       kCDO_Update_Source_SelectPFI2              = 3,
>>>>       kCDO_Update_Source_SelectPFI3              = 4,
>>>>       kCDO_Update_Source_SelectPFI4              = 5,
>>>>       kCDO_Update_Source_SelectPFI5              = 6,
>>>>       kCDO_Update_Source_SelectPFI6              = 7,
>>>>       kCDO_Update_Source_SelectPFI7              = 8,
>>>>       kCDO_Update_Source_SelectPFI8              = 9,
>>>>       kCDO_Update_Source_SelectPFI9              = 10,
>>>>       kCDO_Update_Source_SelectRTSI0             = 11,
>>>>       kCDO_Update_Source_SelectRTSI1             = 12,
>>>>       kCDO_Update_Source_SelectRTSI2             = 13,
>>>>       kCDO_Update_Source_SelectRTSI3             = 14,
>>>>       kCDO_Update_Source_SelectRTSI4             = 15,
>>>>       kCDO_Update_Source_SelectRTSI5             = 16,
>>>>       kCDO_Update_Source_SelectRTSI6             = 17,
>>>>       kCDO_Update_Source_SelectAI_Start          = 18,
>>>>       kCDO_Update_Source_SelectAI_Convert        = 19,
>>>>       kCDO_Update_Source_SelectPXI_Star_Trigger  = 20,
>>>>       kCDO_Update_Source_SelectPFI10             = 21,
>>>>       kCDO_Update_Source_SelectPFI11             = 22,
>>>>       kCDO_Update_Source_SelectPFI12             = 23,
>>>>       kCDO_Update_Source_SelectPFI13             = 24,
>>>>       kCDO_Update_Source_SelectPFI14             = 25,
>>>>       kCDO_Update_Source_SelectPFI15             = 26,
>>>>       kCDO_Update_Source_SelectRTSI7             = 27,
>>>>       kCDO_Update_Source_SelectG0_Out            = 28,
>>>>       kCDO_Update_Source_SelectG1_Out            = 29,
>>>>       kCDO_Update_Source_SelectAnalog_Trigger    = 30,
>>>>       kCDO_Update_Source_SelectAO_Update         = 31,
>>>>       kCDO_Update_Source_SelectFreq_Out          = 32,
>>>>       kCDO_Update_Source_SelectDIO_Change_Detect_Irq       = 33,
>>>>    } tCDO_Update_Source_Select;
>>>> 
>>>> So, Stefan, here is a quick solution:
>>>> 
>>>> if you have access to your board you can choose one of these signals
>>>> (in which a regular pulse is occuring) and you can modify accordingly
>>>> the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c. 
>>>> 
>>>>> 
>>>>>> Best wishes,
>>>>>> 
>>>>>> -Stefan
>>>>>> 
>>>>>> 
>>>>>> On Jun 30, 2010, at 15:45, Alexis Berlemont wrote:
>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> Stefan Schaal wrote:
>>>>>>>> Hi Alexis,
>>>>>>>> 
>>>>>>>> I did a reboot, ran my modified cmd_bits.c again one time. 
>>>>>>>> 
>>>>>>>> cat /proc/xenomai/irq  reports:
>>>>>>>> 
>>>>>>>> IRQ         CPU0        CPU1        CPU2        CPU3        CPU4        CPU5        CPU6        CPU7
>>>>>>>> 56:           0           0           0           0           0           0           0           0         Analogy device
>>>>>>>> 518:           0           1           1           1           1           1           1           1         [IPI]
>>>>>>>> 521:      626392      618020      618539      620274      617326      625008      622464      626300         [timer]
>>>>>>>> 522:           0           0           0           0           0           0           0           0         [critical sync]
>>>>>>>> 546:           0           0           0           0           0           0           0           0         [virtual]
>>>>>>>> 
>>>>>>> 
>>>>>>> I have not forgotten you. I am still stuck with your bug: The mite
>>>>>>> transfers the first 8000 bytes and after does nothing; no interrupt is
>>>>>>> generated by the mite so as to finally awake your application. 
>>>>>>> 
>>>>>>> It seems like the data retrieved by the mite are not consumed by the
>>>>>>> board. Are you sure the digital output lines correspond to what you
>>>>>>> configured with cmd_bits ? 
>>>>>>> 
>>>>>>> I think the digital output is misconfigured. I am working on it.
>>>>>>> 
>>>>>>>> 
>>>>>>>> -Stefan
>>>>>>>> 
>>>>>>>> On Jun 27, 2010, at 3:37, Alexis Berlemont wrote:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Stefan Schaal wrote:
>>>>>>>>>> Hi Alexis,
>>>>>>>>>> 
>>>>>>>>>> thanks so much for the new analogy software. Here are some first observations:
>>>>>>>>>> 
>>>>>>>>>> 1) cmd_bits.c works fine on our NI6250 board
>>>>>>>>>> 
>>>>>>>>>> 2) however, a slightly modified version hangs -- I appended my cmd_bits.c to this email. All what I added is a for loop around the a4l_async_write() and a4l_snd_insn() commands, i.e., I wanted to trigger a write repeatedly. Look for the "sschaal" comment in my modified cmd_bits.c .  After 32 iterations, cmd_bits hangs, no error messages in dmesg. Interesting, when I change your "trigger_threshold" variable from 128 to 256, my loop runs for 16 iterations (other changes of the trigger threshold adjust the number of iterations I get in a similar way). Thus, it feels like there is a buffer which does not get reset after a4l_snd_insn() is called -- does this make sense?
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Could you tell me if the mite triggered an interrupt ? Could you send
>>>>>>>>> a dump of cat /proc/xenomai/irq after having made the test program
>>>>>>>>> hang ?
>>>>>>>>> 
>>>>>>>>> Many thanks,
>>>>>>>>> 
>>>>>>>>>> Best wishes,
>>>>>>>>>> 
>>>>>>>>>> -Stefan
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Jun 24, 2010, at 15:43, Alexis Berlemont wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> Alexis Berlemont wrote:
>>>>>>>>>>>> Hi Stefan,
>>>>>>>>>>>> 
>>>>>>>>>>>> Stefan Schaal wrote:
>>>>>>>>>>>>> Hi Alexis,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I was just wondering whether the new "experimental" branch in your git repository is something that can be tried already.
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> No. Not yet. This branch is aimed at temporarily holding the
>>>>>>>>>>>> corrections I am trying to do for the cmd_bits issue. It needs quite a
>>>>>>>>>>>> lot of work and I have not finished yet. 
>>>>>>>>>>>> 
>>>>>>>>>>>> If you have a look at the commits in this branch, we will see many
>>>>>>>>>>>> "(broken)".
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> I just rebased the experimental branch into the branch analogy. So,
>>>>>>>>>>> starting from now, we should be able to properly use cmd_bits with a
>>>>>>>>>>> clone of my git repository.
>>>>>>>>>>> 
>>>>>>>>>>> After having reworked the asynchronous buffer subsystem (and having
>>>>>>>>>>> fixed some oops in the NI driver and in the new code), cmd_bits can
>>>>>>>>>>> correctly communicate with the DIO subdevice. 
>>>>>>>>>>> 
>>>>>>>>>>> A command like "./cmd_bits 0xffff 0xffff" works on my
>>>>>>>>>>> board. Unfortunately, I have not done the necessary to check the
>>>>>>>>>>> digital output lines yet.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>>> Best wishes,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -Stefan
>>>>>>>>>>>> 
>>>>>>>>>>>> -- 
>>>>>>>>>>>> Alexis.
>>>>>>>>>>> 
>>>>>>>>>>> -- 
>>>>>>>>>>> Alexis.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> ======================================================= cmd_bits.c ==================================================
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -- 
>>>>>>>>> Alexis.
>>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> Alexis.
>>>>>> 
>>>>> 
>>>>> -- 
>>>>> Alexis.
>>>> 
>>>> -- 
>>>> Alexis.
>>> 
>> 
>> -- 
>> Alexis.
> 
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] analogy - experimental branch

[Alexis Berlemont]

Hi,

Stefan Schaal wrote:
> Hi Alexis,
> 
>   I guess I slowly understand that my clocking signal connected to
>   scan_begin_arg has to come from an external DIO input, if
>   scan_bigin_src = TRIG_EXT, and that the insn instruction is still
>   needed to trigger the entire acquisition. 

Yes. The trigger instruction is needed so as to start the whole
acquisition (which is composed of many scans). A periodic external
signal is needed so as to trigger each scan.

> 
>   Alternatively, would it be possible to use the internal clocking signals like 
> 
> scan_bigin_src = TRIG_FOLLOW
> 
> or 
> 
> scan_bigin_src = TRIG_TIMER

I think you are right. If the sampling clock comes from another
subdevice, TRIG_EXT may not be the most appropriate constant. However,
the original comedi driver only expects TRIG_EXT even if... the
sampling signal is not external.

TRIG_TIMER does not seem suitable because it assumes an independant
sampling clock is available.  

And TRIG_FOLLOW may be the most appropriate one. We should modify the
driver so that TRIG_FOLLOW is used if the analog sampling clock is
chosen.

> 
> 
> if I try any of these sources, I get an error -22, and dmesg reports:
> 
> [195882.321300] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported
> 

For me, the command interface is an empty shell because the various
parameters (start_src, scan_begin_src, ...) and the values (TRIG_*)
are imposed. And, on the other side, the driver is fully in charge of
the command structure as it is. So, the comedi command imposes a
communication method but does not ease the driver's task of managing
it (errors checking, translation, etc.)

And, in our case: DIO, we may conclude that this imposed API does not
fit well: in scan_begin_arg, we have to pass an index which is
supposed to correspond to some sampling clock (which is specific to a
board). Then, we use a generic interface with board-specific
arguments.

So, to sum up, I understand your point: the way we control the driver
may not always be the most appropriate one. But, we inherited from
comedi both the interface and the drivers. 

On my side, I am working on trying to implement (as a background task)
a generic interface a little bit more based on discovery (query /
enum) that would render the command interface obsolete. Unfortunately,
I have nothing interesting to show yet.

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

-- 
Alexis.

Re: [Xenomai-core] analogy - experimental branch

[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
>> 
>> 
> 

Re: [Xenomai-core] analogy - experimental branch

[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@domain.hid
> https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] analogy - experimental branch

[Alexis Berlemont]

Stefan Schaal wrote:
> Hi Alexis,
> 
>   maybe it is more useful to mention what I actually want to achieve with DIO on my NI6259.  My DIO communication involves a series of interactions with another board to collect sensory data from a robot, and to send out commands to this board. For instance, to read one of the sensors, a sequence of DIO values need to be written to tell the board to send the data. I programmed this initially with synchronous instructions using a4l_sync_dio(), but this turns out to be too slow. Thus, the hope is to use commands, i.e., fill the FIFO with the sequence of values which I need to execute, and then use asynchronous DIO to obtain much higher speed of communicating the values in the FIFO.
> 
>    Thus, what I essentially try to do is to put about 10-20 scans in the FIFO, and then write the FIFO as fast as possible to my NI6259 DIO subdevice.
> 
> Would you have any ideas how to do this fast writing of the scans in the FIFO with the current analogy functionality?
> 
Right now, I don't know. I think your idea of using DIO commands may
be suitable (I don't know your timing constraints). So what not
proceeding ?

> Thanks a lot!
> 
> -Stefan
> 
> 
> On Jul 12, 2010, at 22:51, Stefan Schaal wrote:
> 
> > Hi Alexis,
> > 
> >  thanks a lot for the explanations. One item I am confused about is that you write that TRIG_TIMER is not suitable for DIO, but in cmd_write.c in your sample code, it is used for the analog write without problems. Wouldn't one be able to just use the same clock source for DIO as in analogue I/O?
> > 
> > Best wishes,
> > 
> > -Stefan
> > 
> > 
> > 
> > On Jul 12, 2010, at 15:29, Alexis Berlemont wrote:
> > 
> >> Hi,
> >> 
> >> Stefan Schaal wrote:
> >>> Hi Alexis,
> >>> 
> >>> I guess I slowly understand that my clocking signal connected to
> >>> scan_begin_arg has to come from an external DIO input, if
> >>> scan_bigin_src = TRIG_EXT, and that the insn instruction is still
> >>> needed to trigger the entire acquisition. 
> >> 
> >> Yes. The trigger instruction is needed so as to start the whole
> >> acquisition (which is composed of many scans). A periodic external
> >> signal is needed so as to trigger each scan.
> >> 
> >>> 
> >>> Alternatively, would it be possible to use the internal clocking signals like 
> >>> 
> >>> scan_bigin_src = TRIG_FOLLOW
> >>> 
> >>> or 
> >>> 
> >>> scan_bigin_src = TRIG_TIMER
> >> 
> >> I think you are right. If the sampling clock comes from another
> >> subdevice, TRIG_EXT may not be the most appropriate constant. However,
> >> the original comedi driver only expects TRIG_EXT even if... the
> >> sampling signal is not external.
> >> 
> >> TRIG_TIMER does not seem suitable because it assumes an independant
> >> sampling clock is available.  
> >> 
> >> And TRIG_FOLLOW may be the most appropriate one. We should modify the
> >> driver so that TRIG_FOLLOW is used if the analog sampling clock is
> >> chosen.
> >> 
> >>> 
> >>> 
> >>> if I try any of these sources, I get an error -22, and dmesg reports:
> >>> 
> >>> [195882.321300] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported
> >>> 
> >> 
> >> For me, the command interface is an empty shell because the various
> >> parameters (start_src, scan_begin_src, ...) and the values (TRIG_*)
> >> are imposed. And, on the other side, the driver is fully in charge of
> >> the command structure as it is. So, the comedi command imposes a
> >> communication method but does not ease the driver's task of managing
> >> it (errors checking, translation, etc.)
> >> 
> >> And, in our case: DIO, we may conclude that this imposed API does not
> >> fit well: in scan_begin_arg, we have to pass an index which is
> >> supposed to correspond to some sampling clock (which is specific to a
> >> board). Then, we use a generic interface with board-specific
> >> arguments.
> >> 
> >> So, to sum up, I understand your point: the way we control the driver
> >> may not always be the most appropriate one. But, we inherited from
> >> comedi both the interface and the drivers. 
> >> 
> >> On my side, I am working on trying to implement (as a background task)
> >> a generic interface a little bit more based on discovery (query /
> >> enum) that would render the command interface obsolete. Unfortunately,
> >> I have nothing interesting to show yet.
> >> 
> >>> Best wishes,
> >>> 
> >>> -STefan
> >>> 
> >>> 
> >> 
> > 
> > 
> > _______________________________________________
> > Xenomai-core mailing list
> > Xenomai-core@domain.hid
> > https://mail.gna.org/listinfo/xenomai-core
> 

-- 
Alexis.

Re: [Xenomai-core] analogy - experimental branch

[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 list
>>> Xenomai-core@domain.hid
>>> https://mail.gna.org/listinfo/xenomai-core
>> 
> 
> -- 
> Alexis.

Re: [Xenomai-core] analogy - experimental branch

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

Re: [Xenomai-core] analogy - experimental branch

[Alexis Berlemont]

Hi,

Sorry for answering late. 

Stefan Schaal wrote:
> Hi Alexis,
> 
>   I managed to port some of the Comedi examples to Analogy. In particular, I could configure one of my counter subdevices to become a high frequency clock, following the gpct_pulse_generator.c example. I routed the output of the clock to my PFI0 pin, and could visualize the signal on an oscilloscope. Thus, I know have the clock I need to trigger CMD-based DIO, as you suggested. (I will post some sample code of this in the near future after all is cleaned up).
> 
>    Next, I went back to cmd_bits.c and try to make it work on my NI6259 board. For scan_begin_src=TRIG_EXT   I need to choose scan_begin_arg = 28 (which is kCDO_Update_Source_SelectG0_Out in the NI documentation, and NI_CDIO_SCAN_BEGIN_SRC_G0_OUT in the comedi.h file).
> 
>    When running cmd_bits.c in this way and monitoring the DO channels on an oscilloscope, the DO switches to HIGH when the acquisition is triggered (i.e., the value of the first element in the FIFO), but the FIFO is not processed any further, i.e., not emptied. If I DO NOT run the counter-clock above, the DO does not even switch to HIGH. I also checked whether 28 is the right value for scan_begin_arg by trying a wide range of values, but only for scan_begin_arg = 28 I get the DO bit switched to HIGH at the beginning of the acquisition.
> 
>   In Comedi, the cmd.flags is set to CMDF_WRITE for such externally triggered acquisitions, which I tried, but it did not help.
> 
>   Thus, it appears that I still have a problem in processing the FIFO, despite it appears that all other things are now correctly connected (Comedi has an example do_waveform.c, which is pretty much what I try to use for testing in my own code).
> 
>   Would you have any thoughts on what might go wrong? It looks like we are just a tiny bit away from succeeding with cmd_bits.c on my board.
> 

I had time to have a look at your problem. Unfortunately, I do not
have any solution. I just have some questions you may find stupid:

- Did you try to invert the sample clock polarity by setting the flag
  CR_INVERT in the command field scan_begin_arg?
- Which frequencies did you generate with the counter subdevice? Even
  the lowest one did nothing (Something like 10Hz)?
- Did you try to send 0 with cmd_bits ? Just to check that the DO stay
  to LOW, which would mean that the values (or at least the first one)
  are properly loaded into the device.
- So far, cmd_bits always sends the same value (the one you passed as
  argument); we should modify it so that the complement value is
  written every two samples. That would allow us to physically check
  how many samples are "played" by the DO. 

> Best wishes,
> 
> -Stefan
> 
> 
> 
> 
> 
> On Jul 14, 2010, at 17:46, Stefan Schaal wrote:
> 
> > Hi Alexis,
> > 
> >  in the Comedi examples (http://www.comedi.org/download/comedilib-0.8.1.tar.gz, the do_waveform.c example), they suggest to use a general purpose counter as clocking input to a cmd-based DIO acquisition. This seems to be the signal "kCDO_Update_Source_SelectG0_Out            = 28" from the enum you found in the NI documentation.
> > 
> > For this purpose, the counter needs to be configured and triggered. Does Analogy already have the functionality to do such operations? The Comedi libraries have an example for this, too, in gpct_pulse_generator.c, just that this example uses a variety of function calls that I cannot directly map to the current Analogy functionality.
> > 
> > Or, do you happen to know whether there is another, easier to access, clock source?
> > 
> > Best wishes,
> > 
> > -Stefan
> > 
> > 
> > On Jul 14, 2010, at 14:03, Alexis Berlemont wrote:
> > 
> >> Stefan Schaal wrote:
> >>> Hi Alexis,
> >>> 
> >>> maybe it is more useful to mention what I actually want to achieve with DIO on my NI6259.  My DIO communication involves a series of interactions with another board to collect sensory data from a robot, and to send out commands to this board. For instance, to read one of the sensors, a sequence of DIO values need to be written to tell the board to send the data. I programmed this initially with synchronous instructions using a4l_sync_dio(), but this turns out to be too slow. Thus, the hope is to use commands, i.e., fill the FIFO with the sequence of values which I need to execute, and then use asynchronous DIO to obtain much higher speed of communicating the values in the FIFO.
> >>> 
> >>>  Thus, what I essentially try to do is to put about 10-20 scans in the FIFO, and then write the FIFO as fast as possible to my NI6259 DIO subdevice.
> >>> 
> >>> Would you have any ideas how to do this fast writing of the scans in the FIFO with the current analogy functionality?
> >>> 
> >> Right now, I don't know. I think your idea of using DIO commands may
> >> be suitable (I don't know your timing constraints). So what not
> >> proceeding ?
> >> 
> >>> Thanks a lot!
> >>> 
> >>> -Stefan
> >>> 
> >>> 
> >>> On Jul 12, 2010, at 22:51, Stefan Schaal wrote:
> >>> 
> >>>> Hi Alexis,
> >>>> 
> >>>> thanks a lot for the explanations. One item I am confused about is that you write that TRIG_TIMER is not suitable for DIO, but in cmd_write.c in your sample code, it is used for the analog write without problems. Wouldn't one be able to just use the same clock source for DIO as in analogue I/O?
> >>>> 
> >>>> Best wishes,
> >>>> 
> >>>> -Stefan
> >>>> 
> >>>> 
> >>>> 
> >>>> On Jul 12, 2010, at 15:29, Alexis Berlemont wrote:
> >>>> 
> >>>>> Hi,
> >>>>> 
> >>>>> Stefan Schaal wrote:
> >>>>>> Hi Alexis,
> >>>>>> 
> >>>>>> I guess I slowly understand that my clocking signal connected to
> >>>>>> scan_begin_arg has to come from an external DIO input, if
> >>>>>> scan_bigin_src = TRIG_EXT, and that the insn instruction is still
> >>>>>> needed to trigger the entire acquisition. 
> >>>>> 
> >>>>> Yes. The trigger instruction is needed so as to start the whole
> >>>>> acquisition (which is composed of many scans). A periodic external
> >>>>> signal is needed so as to trigger each scan.
> >>>>> 
> >>>>>> 
> >>>>>> Alternatively, would it be possible to use the internal clocking signals like 
> >>>>>> 
> >>>>>> scan_bigin_src = TRIG_FOLLOW
> >>>>>> 
> >>>>>> or 
> >>>>>> 
> >>>>>> scan_bigin_src = TRIG_TIMER
> >>>>> 
> >>>>> I think you are right. If the sampling clock comes from another
> >>>>> subdevice, TRIG_EXT may not be the most appropriate constant. However,
> >>>>> the original comedi driver only expects TRIG_EXT even if... the
> >>>>> sampling signal is not external.
> >>>>> 
> >>>>> TRIG_TIMER does not seem suitable because it assumes an independant
> >>>>> sampling clock is available.  
> >>>>> 
> >>>>> And TRIG_FOLLOW may be the most appropriate one. We should modify the
> >>>>> driver so that TRIG_FOLLOW is used if the analog sampling clock is
> >>>>> chosen.
> >>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> if I try any of these sources, I get an error -22, and dmesg reports:
> >>>>>> 
> >>>>>> [195882.321300] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported
> >>>>>> 
> >>>>> 
> >>>>> For me, the command interface is an empty shell because the various
> >>>>> parameters (start_src, scan_begin_src, ...) and the values (TRIG_*)
> >>>>> are imposed. And, on the other side, the driver is fully in charge of
> >>>>> the command structure as it is. So, the comedi command imposes a
> >>>>> communication method but does not ease the driver's task of managing
> >>>>> it (errors checking, translation, etc.)
> >>>>> 
> >>>>> And, in our case: DIO, we may conclude that this imposed API does not
> >>>>> fit well: in scan_begin_arg, we have to pass an index which is
> >>>>> supposed to correspond to some sampling clock (which is specific to a
> >>>>> board). Then, we use a generic interface with board-specific
> >>>>> arguments.
> >>>>> 
> >>>>> So, to sum up, I understand your point: the way we control the driver
> >>>>> may not always be the most appropriate one. But, we inherited from
> >>>>> comedi both the interface and the drivers. 
> >>>>> 
> >>>>> On my side, I am working on trying to implement (as a background task)
> >>>>> a generic interface a little bit more based on discovery (query /
> >>>>> enum) that would render the command interface obsolete. Unfortunately,
> >>>>> I have nothing interesting to show yet.
> >>>>> 
> >>>>>> Best wishes,
> >>>>>> 
> >>>>>> -STefan
> >>>>>> 
> >>>>>> 
> >>>>> 
> >>>> 
> >>>> 
> >>>> _______________________________________________
> >>>> Xenomai-core mailing list
> >>>> Xenomai-core@domain.hid
> >>>> https://mail.gna.org/listinfo/xenomai-core
> >>> 
> >> 
> >> -- 
> >> Alexis.
> > 
> > 
> > _______________________________________________
> > Xenomai-core mailing list
> > Xenomai-core@domain.hid
> > https://mail.gna.org/listinfo/xenomai-core
> 

-- 
Alexis.

Re: [Xenomai-core] analogy - experimental branch

[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 0xffffffff and 0x0 values to the devices to generate a square wave on the oscilloscope. I cannot see anything of the square wave executed.

Best wishes,

-Stefan


On Jul 19, 2010, at 15:01, Alexis Berlemont wrote:

> Hi,
> 
> Sorry for answering late. 
> 
> Stefan Schaal wrote:
>> Hi Alexis,
>> 
>>  I managed to port some of the Comedi examples to Analogy. In particular, I could configure one of my counter subdevices to become a high frequency clock, following the gpct_pulse_generator.c example. I routed the output of the clock to my PFI0 pin, and could visualize the signal on an oscilloscope. Thus, I know have the clock I need to trigger CMD-based DIO, as you suggested. (I will post some sample code of this in the near future after all is cleaned up).
>> 
>>   Next, I went back to cmd_bits.c and try to make it work on my NI6259 board. For scan_begin_src=TRIG_EXT   I need to choose scan_begin_arg = 28 (which is kCDO_Update_Source_SelectG0_Out in the NI documentation, and NI_CDIO_SCAN_BEGIN_SRC_G0_OUT in the comedi.h file).
>> 
>>   When running cmd_bits.c in this way and monitoring the DO channels on an oscilloscope, the DO switches to HIGH when the acquisition is triggered (i.e., the value of the first element in the FIFO), but the FIFO is not processed any further, i.e., not emptied. If I DO NOT run the counter-clock above, the DO does not even switch to HIGH. I also checked whether 28 is the right value for scan_begin_arg by trying a wide range of values, but only for scan_begin_arg = 28 I get the DO bit switched to HIGH at the beginning of the acquisition.
>> 
>>  In Comedi, the cmd.flags is set to CMDF_WRITE for such externally triggered acquisitions, which I tried, but it did not help.
>> 
>>  Thus, it appears that I still have a problem in processing the FIFO, despite it appears that all other things are now correctly connected (Comedi has an example do_waveform.c, which is pretty much what I try to use for testing in my own code).
>> 
>>  Would you have any thoughts on what might go wrong? It looks like we are just a tiny bit away from succeeding with cmd_bits.c on my board.
>> 
> 
> I had time to have a look at your problem. Unfortunately, I do not
> have any solution. I just have some questions you may find stupid:
> 
> - Did you try to invert the sample clock polarity by setting the flag
>  CR_INVERT in the command field scan_begin_arg?
> - Which frequencies did you generate with the counter subdevice? Even
>  the lowest one did nothing (Something like 10Hz)?
> - Did you try to send 0 with cmd_bits ? Just to check that the DO stay
>  to LOW, which would mean that the values (or at least the first one)
>  are properly loaded into the device.
> - So far, cmd_bits always sends the same value (the one you passed as
>  argument); we should modify it so that the complement value is
>  written every two samples. That would allow us to physically check
>  how many samples are "played" by the DO. 
> 
>> Best wishes,
>> 
>> -Stefan
>> 
>> 
>> 
>> 
>> 
>> On Jul 14, 2010, at 17:46, Stefan Schaal wrote:
>> 
>>> Hi Alexis,
>>> 
>>> in the Comedi examples (http://www.comedi.org/download/comedilib-0.8.1.tar.gz, the do_waveform.c example), they suggest to use a general purpose counter as clocking input to a cmd-based DIO acquisition. This seems to be the signal "kCDO_Update_Source_SelectG0_Out            = 28" from the enum you found in the NI documentation.
>>> 
>>> For this purpose, the counter needs to be configured and triggered. Does Analogy already have the functionality to do such operations? The Comedi libraries have an example for this, too, in gpct_pulse_generator.c, just that this example uses a variety of function calls that I cannot directly map to the current Analogy functionality.
>>> 
>>> Or, do you happen to know whether there is another, easier to access, clock source?
>>> 
>>> Best wishes,
>>> 
>>> -Stefan
>>> 
>>> 
>>> On Jul 14, 2010, at 14:03, Alexis Berlemont wrote:
>>> 
>>>> Stefan Schaal wrote:
>>>>> Hi Alexis,
>>>>> 
>>>>> maybe it is more useful to mention what I actually want to achieve with DIO on my NI6259.  My DIO communication involves a series of interactions with another board to collect sensory data from a robot, and to send out commands to this board. For instance, to read one of the sensors, a sequence of DIO values need to be written to tell the board to send the data. I programmed this initially with synchronous instructions using a4l_sync_dio(), but this turns out to be too slow. Thus, the hope is to use commands, i.e., fill the FIFO with the sequence of values which I need to execute, and then use asynchronous DIO to obtain much higher speed of communicating the values in the FIFO.
>>>>> 
>>>>> Thus, what I essentially try to do is to put about 10-20 scans in the FIFO, and then write the FIFO as fast as possible to my NI6259 DIO subdevice.
>>>>> 
>>>>> Would you have any ideas how to do this fast writing of the scans in the FIFO with the current analogy functionality?
>>>>> 
>>>> Right now, I don't know. I think your idea of using DIO commands may
>>>> be suitable (I don't know your timing constraints). So what not
>>>> proceeding ?
>>>> 
>>>>> Thanks a lot!
>>>>> 
>>>>> -Stefan
>>>>> 
>>>>> 
>>>>> On Jul 12, 2010, at 22:51, Stefan Schaal wrote:
>>>>> 
>>>>>> Hi Alexis,
>>>>>> 
>>>>>> thanks a lot for the explanations. One item I am confused about is that you write that TRIG_TIMER is not suitable for DIO, but in cmd_write.c in your sample code, it is used for the analog write without problems. Wouldn't one be able to just use the same clock source for DIO as in analogue I/O?
>>>>>> 
>>>>>> Best wishes,
>>>>>> 
>>>>>> -Stefan
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Jul 12, 2010, at 15:29, Alexis Berlemont wrote:
>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> Stefan Schaal wrote:
>>>>>>>> Hi Alexis,
>>>>>>>> 
>>>>>>>> I guess I slowly understand that my clocking signal connected to
>>>>>>>> scan_begin_arg has to come from an external DIO input, if
>>>>>>>> scan_bigin_src = TRIG_EXT, and that the insn instruction is still
>>>>>>>> needed to trigger the entire acquisition. 
>>>>>>> 
>>>>>>> Yes. The trigger instruction is needed so as to start the whole
>>>>>>> acquisition (which is composed of many scans). A periodic external
>>>>>>> signal is needed so as to trigger each scan.
>>>>>>> 
>>>>>>>> 
>>>>>>>> Alternatively, would it be possible to use the internal clocking signals like 
>>>>>>>> 
>>>>>>>> scan_bigin_src = TRIG_FOLLOW
>>>>>>>> 
>>>>>>>> or 
>>>>>>>> 
>>>>>>>> scan_bigin_src = TRIG_TIMER
>>>>>>> 
>>>>>>> I think you are right. If the sampling clock comes from another
>>>>>>> subdevice, TRIG_EXT may not be the most appropriate constant. However,
>>>>>>> the original comedi driver only expects TRIG_EXT even if... the
>>>>>>> sampling signal is not external.
>>>>>>> 
>>>>>>> TRIG_TIMER does not seem suitable because it assumes an independant
>>>>>>> sampling clock is available.  
>>>>>>> 
>>>>>>> And TRIG_FOLLOW may be the most appropriate one. We should modify the
>>>>>>> driver so that TRIG_FOLLOW is used if the analog sampling clock is
>>>>>>> chosen.
>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> if I try any of these sources, I get an error -22, and dmesg reports:
>>>>>>>> 
>>>>>>>> [195882.321300] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported
>>>>>>>> 
>>>>>>> 
>>>>>>> For me, the command interface is an empty shell because the various
>>>>>>> parameters (start_src, scan_begin_src, ...) and the values (TRIG_*)
>>>>>>> are imposed. And, on the other side, the driver is fully in charge of
>>>>>>> the command structure as it is. So, the comedi command imposes a
>>>>>>> communication method but does not ease the driver's task of managing
>>>>>>> it (errors checking, translation, etc.)
>>>>>>> 
>>>>>>> And, in our case: DIO, we may conclude that this imposed API does not
>>>>>>> fit well: in scan_begin_arg, we have to pass an index which is
>>>>>>> supposed to correspond to some sampling clock (which is specific to a
>>>>>>> board). Then, we use a generic interface with board-specific
>>>>>>> arguments.
>>>>>>> 
>>>>>>> So, to sum up, I understand your point: the way we control the driver
>>>>>>> may not always be the most appropriate one. But, we inherited from
>>>>>>> comedi both the interface and the drivers. 
>>>>>>> 
>>>>>>> On my side, I am working on trying to implement (as a background task)
>>>>>>> a generic interface a little bit more based on discovery (query /
>>>>>>> enum) that would render the command interface obsolete. Unfortunately,
>>>>>>> I have nothing interesting to show yet.
>>>>>>> 
>>>>>>>> Best wishes,
>>>>>>>> 
>>>>>>>> -STefan
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Xenomai-core mailing list
>>>>>> Xenomai-core@domain.hid
>>>>>> https://mail.gna.org/listinfo/xenomai-core
>>>>> 
>>>> 
>>>> -- 
>>>> Alexis.
>>> 
>>> 
>>> _______________________________________________
>>> Xenomai-core mailing list
>>> Xenomai-core@domain.hid
>>> https://mail.gna.org/listinfo/xenomai-core
>> 
> 
> -- 
> Alexis.

Re: [Xenomai-core] analogy - experimental branch

[Alexis Berlemont]

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 0xffffffff and 0x0 values to the devices to generate a square wave on the oscilloscope. I cannot see anything of the square wave executed.
> 

At last, it comes!!!

Thanks to your test program and your help, I think I have fixed this
bug. Could you clone my git repository (branch analogy), and give it a
try with your own test program.

There was a bug in the mite configuration which explained why the
wrong data were sent to the DIO subdevice. That was also the reason
why no interrupt came from the mite.

> Best wishes,
> 
> -Stefan
> 
> 
> On Jul 19, 2010, at 15:01, Alexis Berlemont wrote:
> 
> > Hi,
> > 
> > Sorry for answering late. 
> > 
> > Stefan Schaal wrote:
> >> Hi Alexis,
> >> 
> >>  I managed to port some of the Comedi examples to Analogy. In particular, I could configure one of my counter subdevices to become a high frequency clock, following the gpct_pulse_generator.c example. I routed the output of the clock to my PFI0 pin, and could visualize the signal on an oscilloscope. Thus, I know have the clock I need to trigger CMD-based DIO, as you suggested. (I will post some sample code of this in the near future after all is cleaned up).
> >> 
> >>   Next, I went back to cmd_bits.c and try to make it work on my NI6259 board. For scan_begin_src=TRIG_EXT   I need to choose scan_begin_arg = 28 (which is kCDO_Update_Source_SelectG0_Out in the NI documentation, and NI_CDIO_SCAN_BEGIN_SRC_G0_OUT in the comedi.h file).
> >> 
> >>   When running cmd_bits.c in this way and monitoring the DO channels on an oscilloscope, the DO switches to HIGH when the acquisition is triggered (i.e., the value of the first element in the FIFO), but the FIFO is not processed any further, i.e., not emptied. If I DO NOT run the counter-clock above, the DO does not even switch to HIGH. I also checked whether 28 is the right value for scan_begin_arg by trying a wide range of values, but only for scan_begin_arg = 28 I get the DO bit switched to HIGH at the beginning of the acquisition.
> >> 
> >>  In Comedi, the cmd.flags is set to CMDF_WRITE for such externally triggered acquisitions, which I tried, but it did not help.
> >> 
> >>  Thus, it appears that I still have a problem in processing the FIFO, despite it appears that all other things are now correctly connected (Comedi has an example do_waveform.c, which is pretty much what I try to use for testing in my own code).
> >> 
> >>  Would you have any thoughts on what might go wrong? It looks like we are just a tiny bit away from succeeding with cmd_bits.c on my board.
> >> 
> > 
> > I had time to have a look at your problem. Unfortunately, I do not
> > have any solution. I just have some questions you may find stupid:
> > 
> > - Did you try to invert the sample clock polarity by setting the flag
> >  CR_INVERT in the command field scan_begin_arg?
> > - Which frequencies did you generate with the counter subdevice? Even
> >  the lowest one did nothing (Something like 10Hz)?
> > - Did you try to send 0 with cmd_bits ? Just to check that the DO stay
> >  to LOW, which would mean that the values (or at least the first one)
> >  are properly loaded into the device.
> > - So far, cmd_bits always sends the same value (the one you passed as
> >  argument); we should modify it so that the complement value is
> >  written every two samples. That would allow us to physically check
> >  how many samples are "played" by the DO. 
> > 
> >> Best wishes,
> >> 
> >> -Stefan
> >> 
> >> 
> >> 
> >> 
> >> 
> >> On Jul 14, 2010, at 17:46, Stefan Schaal wrote:
> >> 
> >>> Hi Alexis,
> >>> 
> >>> in the Comedi examples (http://www.comedi.org/download/comedilib-0.8.1.tar.gz, the do_waveform.c example), they suggest to use a general purpose counter as clocking input to a cmd-based DIO acquisition. This seems to be the signal "kCDO_Update_Source_SelectG0_Out            = 28" from the enum you found in the NI documentation.
> >>> 
> >>> For this purpose, the counter needs to be configured and triggered. Does Analogy already have the functionality to do such operations? The Comedi libraries have an example for this, too, in gpct_pulse_generator.c, just that this example uses a variety of function calls that I cannot directly map to the current Analogy functionality.
> >>> 
> >>> Or, do you happen to know whether there is another, easier to access, clock source?
> >>> 
> >>> Best wishes,
> >>> 
> >>> -Stefan
> >>> 
> >>> 
> >>> On Jul 14, 2010, at 14:03, Alexis Berlemont wrote:
> >>> 
> >>>> Stefan Schaal wrote:
> >>>>> Hi Alexis,
> >>>>> 
> >>>>> maybe it is more useful to mention what I actually want to achieve with DIO on my NI6259.  My DIO communication involves a series of interactions with another board to collect sensory data from a robot, and to send out commands to this board. For instance, to read one of the sensors, a sequence of DIO values need to be written to tell the board to send the data. I programmed this initially with synchronous instructions using a4l_sync_dio(), but this turns out to be too slow. Thus, the hope is to use commands, i.e., fill the FIFO with the sequence of values which I need to execute, and then use asynchronous DIO to obtain much higher speed of communicating the values in the FIFO.
> >>>>> 
> >>>>> Thus, what I essentially try to do is to put about 10-20 scans in the FIFO, and then write the FIFO as fast as possible to my NI6259 DIO subdevice.
> >>>>> 
> >>>>> Would you have any ideas how to do this fast writing of the scans in the FIFO with the current analogy functionality?
> >>>>> 
> >>>> Right now, I don't know. I think your idea of using DIO commands may
> >>>> be suitable (I don't know your timing constraints). So what not
> >>>> proceeding ?
> >>>> 
> >>>>> Thanks a lot!
> >>>>> 
> >>>>> -Stefan
> >>>>> 
> >>>>> 
> >>>>> On Jul 12, 2010, at 22:51, Stefan Schaal wrote:
> >>>>> 
> >>>>>> Hi Alexis,
> >>>>>> 
> >>>>>> thanks a lot for the explanations. One item I am confused about is that you write that TRIG_TIMER is not suitable for DIO, but in cmd_write.c in your sample code, it is used for the analog write without problems. Wouldn't one be able to just use the same clock source for DIO as in analogue I/O?
> >>>>>> 
> >>>>>> Best wishes,
> >>>>>> 
> >>>>>> -Stefan
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> On Jul 12, 2010, at 15:29, Alexis Berlemont wrote:
> >>>>>> 
> >>>>>>> Hi,
> >>>>>>> 
> >>>>>>> Stefan Schaal wrote:
> >>>>>>>> Hi Alexis,
> >>>>>>>> 
> >>>>>>>> I guess I slowly understand that my clocking signal connected to
> >>>>>>>> scan_begin_arg has to come from an external DIO input, if
> >>>>>>>> scan_bigin_src = TRIG_EXT, and that the insn instruction is still
> >>>>>>>> needed to trigger the entire acquisition. 
> >>>>>>> 
> >>>>>>> Yes. The trigger instruction is needed so as to start the whole
> >>>>>>> acquisition (which is composed of many scans). A periodic external
> >>>>>>> signal is needed so as to trigger each scan.
> >>>>>>> 
> >>>>>>>> 
> >>>>>>>> Alternatively, would it be possible to use the internal clocking signals like 
> >>>>>>>> 
> >>>>>>>> scan_bigin_src = TRIG_FOLLOW
> >>>>>>>> 
> >>>>>>>> or 
> >>>>>>>> 
> >>>>>>>> scan_bigin_src = TRIG_TIMER
> >>>>>>> 
> >>>>>>> I think you are right. If the sampling clock comes from another
> >>>>>>> subdevice, TRIG_EXT may not be the most appropriate constant. However,
> >>>>>>> the original comedi driver only expects TRIG_EXT even if... the
> >>>>>>> sampling signal is not external.
> >>>>>>> 
> >>>>>>> TRIG_TIMER does not seem suitable because it assumes an independant
> >>>>>>> sampling clock is available.  
> >>>>>>> 
> >>>>>>> And TRIG_FOLLOW may be the most appropriate one. We should modify the
> >>>>>>> driver so that TRIG_FOLLOW is used if the analog sampling clock is
> >>>>>>> chosen.
> >>>>>>> 
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> if I try any of these sources, I get an error -22, and dmesg reports:
> >>>>>>>> 
> >>>>>>>> [195882.321300] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported
> >>>>>>>> 
> >>>>>>> 
> >>>>>>> For me, the command interface is an empty shell because the various
> >>>>>>> parameters (start_src, scan_begin_src, ...) and the values (TRIG_*)
> >>>>>>> are imposed. And, on the other side, the driver is fully in charge of
> >>>>>>> the command structure as it is. So, the comedi command imposes a
> >>>>>>> communication method but does not ease the driver's task of managing
> >>>>>>> it (errors checking, translation, etc.)
> >>>>>>> 
> >>>>>>> And, in our case: DIO, we may conclude that this imposed API does not
> >>>>>>> fit well: in scan_begin_arg, we have to pass an index which is
> >>>>>>> supposed to correspond to some sampling clock (which is specific to a
> >>>>>>> board). Then, we use a generic interface with board-specific
> >>>>>>> arguments.
> >>>>>>> 
> >>>>>>> So, to sum up, I understand your point: the way we control the driver
> >>>>>>> may not always be the most appropriate one. But, we inherited from
> >>>>>>> comedi both the interface and the drivers. 
> >>>>>>> 
> >>>>>>> On my side, I am working on trying to implement (as a background task)
> >>>>>>> a generic interface a little bit more based on discovery (query /
> >>>>>>> enum) that would render the command interface obsolete. Unfortunately,
> >>>>>>> I have nothing interesting to show yet.
> >>>>>>> 
> >>>>>>>> Best wishes,
> >>>>>>>> 
> >>>>>>>> -STefan
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> _______________________________________________
> >>>>>> Xenomai-core mailing list
> >>>>>> Xenomai-core@domain.hid
> >>>>>> https://mail.gna.org/listinfo/xenomai-core
> >>>>> 
> >>>> 
> >>>> -- 
> >>>> Alexis.
> >>> 
> >>> 
> >>> _______________________________________________
> >>> Xenomai-core mailing list
> >>> Xenomai-core@domain.hid
> >>> https://mail.gna.org/listinfo/xenomai-core
> >> 
> > 
> > -- 
> > Alexis.
> 

-- 
Alexis.

Re: [Xenomai-core] analogy - experimental branch

[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 0xffffffff and 0x0 values to the devices to generate a square wave on the oscilloscope. I cannot see anything of the square wave executed.
>> 
> 
> At last, it comes!!!
> 
> Thanks to your test program and your help, I think I have fixed this
> bug. Could you clone my git repository (branch analogy), and give it a
> try with your own test program.
> 
> There was a bug in the mite configuration which explained why the
> wrong data were sent to the DIO subdevice. That was also the reason
> why no interrupt came from the mite.
> 
>> Best wishes,
>> 
>> -Stefan
>> 
>> 
>> On Jul 19, 2010, at 15:01, Alexis Berlemont wrote:
>> 
>>> Hi,
>>> 
>>> Sorry for answering late. 
>>> 
>>> Stefan Schaal wrote:
>>>> Hi Alexis,
>>>> 
>>>> I managed to port some of the Comedi examples to Analogy. In particular, I could configure one of my counter subdevices to become a high frequency clock, following the gpct_pulse_generator.c example. I routed the output of the clock to my PFI0 pin, and could visualize the signal on an oscilloscope. Thus, I know have the clock I need to trigger CMD-based DIO, as you suggested. (I will post some sample code of this in the near future after all is cleaned up).
>>>> 
>>>>  Next, I went back to cmd_bits.c and try to make it work on my NI6259 board. For scan_begin_src=TRIG_EXT   I need to choose scan_begin_arg = 28 (which is kCDO_Update_Source_SelectG0_Out in the NI documentation, and NI_CDIO_SCAN_BEGIN_SRC_G0_OUT in the comedi.h file).
>>>> 
>>>>  When running cmd_bits.c in this way and monitoring the DO channels on an oscilloscope, the DO switches to HIGH when the acquisition is triggered (i.e., the value of the first element in the FIFO), but the FIFO is not processed any further, i.e., not emptied. If I DO NOT run the counter-clock above, the DO does not even switch to HIGH. I also checked whether 28 is the right value for scan_begin_arg by trying a wide range of values, but only for scan_begin_arg = 28 I get the DO bit switched to HIGH at the beginning of the acquisition.
>>>> 
>>>> In Comedi, the cmd.flags is set to CMDF_WRITE for such externally triggered acquisitions, which I tried, but it did not help.
>>>> 
>>>> Thus, it appears that I still have a problem in processing the FIFO, despite it appears that all other things are now correctly connected (Comedi has an example do_waveform.c, which is pretty much what I try to use for testing in my own code).
>>>> 
>>>> Would you have any thoughts on what might go wrong? It looks like we are just a tiny bit away from succeeding with cmd_bits.c on my board.
>>>> 
>>> 
>>> I had time to have a look at your problem. Unfortunately, I do not
>>> have any solution. I just have some questions you may find stupid:
>>> 
>>> - Did you try to invert the sample clock polarity by setting the flag
>>> CR_INVERT in the command field scan_begin_arg?
>>> - Which frequencies did you generate with the counter subdevice? Even
>>> the lowest one did nothing (Something like 10Hz)?
>>> - Did you try to send 0 with cmd_bits ? Just to check that the DO stay
>>> to LOW, which would mean that the values (or at least the first one)
>>> are properly loaded into the device.
>>> - So far, cmd_bits always sends the same value (the one you passed as
>>> argument); we should modify it so that the complement value is
>>> written every two samples. That would allow us to physically check
>>> how many samples are "played" by the DO. 
>>> 
>>>> Best wishes,
>>>> 
>>>> -Stefan
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Jul 14, 2010, at 17:46, Stefan Schaal wrote:
>>>> 
>>>>> Hi Alexis,
>>>>> 
>>>>> in the Comedi examples (http://www.comedi.org/download/comedilib-0.8.1.tar.gz, the do_waveform.c example), they suggest to use a general purpose counter as clocking input to a cmd-based DIO acquisition. This seems to be the signal "kCDO_Update_Source_SelectG0_Out            = 28" from the enum you found in the NI documentation.
>>>>> 
>>>>> For this purpose, the counter needs to be configured and triggered. Does Analogy already have the functionality to do such operations? The Comedi libraries have an example for this, too, in gpct_pulse_generator.c, just that this example uses a variety of function calls that I cannot directly map to the current Analogy functionality.
>>>>> 
>>>>> Or, do you happen to know whether there is another, easier to access, clock source?
>>>>> 
>>>>> Best wishes,
>>>>> 
>>>>> -Stefan
>>>>> 
>>>>> 
>>>>> On Jul 14, 2010, at 14:03, Alexis Berlemont wrote:
>>>>> 
>>>>>> Stefan Schaal wrote:
>>>>>>> Hi Alexis,
>>>>>>> 
>>>>>>> maybe it is more useful to mention what I actually want to achieve with DIO on my NI6259.  My DIO communication involves a series of interactions with another board to collect sensory data from a robot, and to send out commands to this board. For instance, to read one of the sensors, a sequence of DIO values need to be written to tell the board to send the data. I programmed this initially with synchronous instructions using a4l_sync_dio(), but this turns out to be too slow. Thus, the hope is to use commands, i.e., fill the FIFO with the sequence of values which I need to execute, and then use asynchronous DIO to obtain much higher speed of communicating the values in the FIFO.
>>>>>>> 
>>>>>>> Thus, what I essentially try to do is to put about 10-20 scans in the FIFO, and then write the FIFO as fast as possible to my NI6259 DIO subdevice.
>>>>>>> 
>>>>>>> Would you have any ideas how to do this fast writing of the scans in the FIFO with the current analogy functionality?
>>>>>>> 
>>>>>> Right now, I don't know. I think your idea of using DIO commands may
>>>>>> be suitable (I don't know your timing constraints). So what not
>>>>>> proceeding ?
>>>>>> 
>>>>>>> Thanks a lot!
>>>>>>> 
>>>>>>> -Stefan
>>>>>>> 
>>>>>>> 
>>>>>>> On Jul 12, 2010, at 22:51, Stefan Schaal wrote:
>>>>>>> 
>>>>>>>> Hi Alexis,
>>>>>>>> 
>>>>>>>> thanks a lot for the explanations. One item I am confused about is that you write that TRIG_TIMER is not suitable for DIO, but in cmd_write.c in your sample code, it is used for the analog write without problems. Wouldn't one be able to just use the same clock source for DIO as in analogue I/O?
>>>>>>>> 
>>>>>>>> Best wishes,
>>>>>>>> 
>>>>>>>> -Stefan
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Jul 12, 2010, at 15:29, Alexis Berlemont wrote:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> Stefan Schaal wrote:
>>>>>>>>>> Hi Alexis,
>>>>>>>>>> 
>>>>>>>>>> I guess I slowly understand that my clocking signal connected to
>>>>>>>>>> scan_begin_arg has to come from an external DIO input, if
>>>>>>>>>> scan_bigin_src = TRIG_EXT, and that the insn instruction is still
>>>>>>>>>> needed to trigger the entire acquisition. 
>>>>>>>>> 
>>>>>>>>> Yes. The trigger instruction is needed so as to start the whole
>>>>>>>>> acquisition (which is composed of many scans). A periodic external
>>>>>>>>> signal is needed so as to trigger each scan.
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Alternatively, would it be possible to use the internal clocking signals like 
>>>>>>>>>> 
>>>>>>>>>> scan_bigin_src = TRIG_FOLLOW
>>>>>>>>>> 
>>>>>>>>>> or 
>>>>>>>>>> 
>>>>>>>>>> scan_bigin_src = TRIG_TIMER
>>>>>>>>> 
>>>>>>>>> I think you are right. If the sampling clock comes from another
>>>>>>>>> subdevice, TRIG_EXT may not be the most appropriate constant. However,
>>>>>>>>> the original comedi driver only expects TRIG_EXT even if... the
>>>>>>>>> sampling signal is not external.
>>>>>>>>> 
>>>>>>>>> TRIG_TIMER does not seem suitable because it assumes an independant
>>>>>>>>> sampling clock is available.  
>>>>>>>>> 
>>>>>>>>> And TRIG_FOLLOW may be the most appropriate one. We should modify the
>>>>>>>>> driver so that TRIG_FOLLOW is used if the analog sampling clock is
>>>>>>>>> chosen.
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> if I try any of these sources, I get an error -22, and dmesg reports:
>>>>>>>>>> 
>>>>>>>>>> [195882.321300] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> For me, the command interface is an empty shell because the various
>>>>>>>>> parameters (start_src, scan_begin_src, ...) and the values (TRIG_*)
>>>>>>>>> are imposed. And, on the other side, the driver is fully in charge of
>>>>>>>>> the command structure as it is. So, the comedi command imposes a
>>>>>>>>> communication method but does not ease the driver's task of managing
>>>>>>>>> it (errors checking, translation, etc.)
>>>>>>>>> 
>>>>>>>>> And, in our case: DIO, we may conclude that this imposed API does not
>>>>>>>>> fit well: in scan_begin_arg, we have to pass an index which is
>>>>>>>>> supposed to correspond to some sampling clock (which is specific to a
>>>>>>>>> board). Then, we use a generic interface with board-specific
>>>>>>>>> arguments.
>>>>>>>>> 
>>>>>>>>> So, to sum up, I understand your point: the way we control the driver
>>>>>>>>> may not always be the most appropriate one. But, we inherited from
>>>>>>>>> comedi both the interface and the drivers. 
>>>>>>>>> 
>>>>>>>>> On my side, I am working on trying to implement (as a background task)
>>>>>>>>> a generic interface a little bit more based on discovery (query /
>>>>>>>>> enum) that would render the command interface obsolete. Unfortunately,
>>>>>>>>> I have nothing interesting to show yet.
>>>>>>>>> 
>>>>>>>>>> Best wishes,
>>>>>>>>>> 
>>>>>>>>>> -STefan
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Xenomai-core mailing list
>>>>>>>> Xenomai-core@domain.hid
>>>>>>>> https://mail.gna.org/listinfo/xenomai-core
>>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Alexis.
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Xenomai-core mailing list
>>>>> Xenomai-core@domain.hid
>>>>> https://mail.gna.org/listinfo/xenomai-core
>>>> 
>>> 
>>> -- 
>>> Alexis.
>> 
> 
> -- 
> Alexis.

Re: [Xenomai-core] analogy - experimental branch

[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 0xffffffff and 0x0 values to the devices to generate a square wave on the oscilloscope. I cannot see anything of the square wave executed.
>>> 
>> 
>> At last, it comes!!!
>> 
>> Thanks to your test program and your help, I think I have fixed this
>> bug. Could you clone my git repository (branch analogy), and give it a
>> try with your own test program.
>> 
>> There was a bug in the mite configuration which explained why the
>> wrong data were sent to the DIO subdevice. That was also the reason
>> why no interrupt came from the mite.
>> 
>>> Best wishes,
>>> 
>>> -Stefan
>>> 
>>> 
>>> On Jul 19, 2010, at 15:01, Alexis Berlemont wrote:
>>> 
>>>> Hi,
>>>> 
>>>> Sorry for answering late. 
>>>> 
>>>> Stefan Schaal wrote:
>>>>> Hi Alexis,
>>>>> 
>>>>> I managed to port some of the Comedi examples to Analogy. In particular, I could configure one of my counter subdevices to become a high frequency clock, following the gpct_pulse_generator.c example. I routed the output of the clock to my PFI0 pin, and could visualize the signal on an oscilloscope. Thus, I know have the clock I need to trigger CMD-based DIO, as you suggested. (I will post some sample code of this in the near future after all is cleaned up).
>>>>> 
>>>>> Next, I went back to cmd_bits.c and try to make it work on my NI6259 board. For scan_begin_src=TRIG_EXT   I need to choose scan_begin_arg = 28 (which is kCDO_Update_Source_SelectG0_Out in the NI documentation, and NI_CDIO_SCAN_BEGIN_SRC_G0_OUT in the comedi.h file).
>>>>> 
>>>>> When running cmd_bits.c in this way and monitoring the DO channels on an oscilloscope, the DO switches to HIGH when the acquisition is triggered (i.e., the value of the first element in the FIFO), but the FIFO is not processed any further, i.e., not emptied. If I DO NOT run the counter-clock above, the DO does not even switch to HIGH. I also checked whether 28 is the right value for scan_begin_arg by trying a wide range of values, but only for scan_begin_arg = 28 I get the DO bit switched to HIGH at the beginning of the acquisition.
>>>>> 
>>>>> In Comedi, the cmd.flags is set to CMDF_WRITE for such externally triggered acquisitions, which I tried, but it did not help.
>>>>> 
>>>>> Thus, it appears that I still have a problem in processing the FIFO, despite it appears that all other things are now correctly connected (Comedi has an example do_waveform.c, which is pretty much what I try to use for testing in my own code).
>>>>> 
>>>>> Would you have any thoughts on what might go wrong? It looks like we are just a tiny bit away from succeeding with cmd_bits.c on my board.
>>>>> 
>>>> 
>>>> I had time to have a look at your problem. Unfortunately, I do not
>>>> have any solution. I just have some questions you may find stupid:
>>>> 
>>>> - Did you try to invert the sample clock polarity by setting the flag
>>>> CR_INVERT in the command field scan_begin_arg?
>>>> - Which frequencies did you generate with the counter subdevice? Even
>>>> the lowest one did nothing (Something like 10Hz)?
>>>> - Did you try to send 0 with cmd_bits ? Just to check that the DO stay
>>>> to LOW, which would mean that the values (or at least the first one)
>>>> are properly loaded into the device.
>>>> - So far, cmd_bits always sends the same value (the one you passed as
>>>> argument); we should modify it so that the complement value is
>>>> written every two samples. That would allow us to physically check
>>>> how many samples are "played" by the DO. 
>>>> 
>>>>> Best wishes,
>>>>> 
>>>>> -Stefan
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Jul 14, 2010, at 17:46, Stefan Schaal wrote:
>>>>> 
>>>>>> Hi Alexis,
>>>>>> 
>>>>>> in the Comedi examples (http://www.comedi.org/download/comedilib-0.8.1.tar.gz, the do_waveform.c example), they suggest to use a general purpose counter as clocking input to a cmd-based DIO acquisition. This seems to be the signal "kCDO_Update_Source_SelectG0_Out            = 28" from the enum you found in the NI documentation.
>>>>>> 
>>>>>> For this purpose, the counter needs to be configured and triggered. Does Analogy already have the functionality to do such operations? The Comedi libraries have an example for this, too, in gpct_pulse_generator.c, just that this example uses a variety of function calls that I cannot directly map to the current Analogy functionality.
>>>>>> 
>>>>>> Or, do you happen to know whether there is another, easier to access, clock source?
>>>>>> 
>>>>>> Best wishes,
>>>>>> 
>>>>>> -Stefan
>>>>>> 
>>>>>> 
>>>>>> On Jul 14, 2010, at 14:03, Alexis Berlemont wrote:
>>>>>> 
>>>>>>> Stefan Schaal wrote:
>>>>>>>> Hi Alexis,
>>>>>>>> 
>>>>>>>> maybe it is more useful to mention what I actually want to achieve with DIO on my NI6259.  My DIO communication involves a series of interactions with another board to collect sensory data from a robot, and to send out commands to this board. For instance, to read one of the sensors, a sequence of DIO values need to be written to tell the board to send the data. I programmed this initially with synchronous instructions using a4l_sync_dio(), but this turns out to be too slow. Thus, the hope is to use commands, i.e., fill the FIFO with the sequence of values which I need to execute, and then use asynchronous DIO to obtain much higher speed of communicating the values in the FIFO.
>>>>>>>> 
>>>>>>>> Thus, what I essentially try to do is to put about 10-20 scans in the FIFO, and then write the FIFO as fast as possible to my NI6259 DIO subdevice.
>>>>>>>> 
>>>>>>>> Would you have any ideas how to do this fast writing of the scans in the FIFO with the current analogy functionality?
>>>>>>>> 
>>>>>>> Right now, I don't know. I think your idea of using DIO commands may
>>>>>>> be suitable (I don't know your timing constraints). So what not
>>>>>>> proceeding ?
>>>>>>> 
>>>>>>>> Thanks a lot!
>>>>>>>> 
>>>>>>>> -Stefan
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Jul 12, 2010, at 22:51, Stefan Schaal wrote:
>>>>>>>> 
>>>>>>>>> Hi Alexis,
>>>>>>>>> 
>>>>>>>>> thanks a lot for the explanations. One item I am confused about is that you write that TRIG_TIMER is not suitable for DIO, but in cmd_write.c in your sample code, it is used for the analog write without problems. Wouldn't one be able to just use the same clock source for DIO as in analogue I/O?
>>>>>>>>> 
>>>>>>>>> Best wishes,
>>>>>>>>> 
>>>>>>>>> -Stefan
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Jul 12, 2010, at 15:29, Alexis Berlemont wrote:
>>>>>>>>> 
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> Stefan Schaal wrote:
>>>>>>>>>>> Hi Alexis,
>>>>>>>>>>> 
>>>>>>>>>>> I guess I slowly understand that my clocking signal connected to
>>>>>>>>>>> scan_begin_arg has to come from an external DIO input, if
>>>>>>>>>>> scan_bigin_src = TRIG_EXT, and that the insn instruction is still
>>>>>>>>>>> needed to trigger the entire acquisition. 
>>>>>>>>>> 
>>>>>>>>>> Yes. The trigger instruction is needed so as to start the whole
>>>>>>>>>> acquisition (which is composed of many scans). A periodic external
>>>>>>>>>> signal is needed so as to trigger each scan.
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Alternatively, would it be possible to use the internal clocking signals like 
>>>>>>>>>>> 
>>>>>>>>>>> scan_bigin_src = TRIG_FOLLOW
>>>>>>>>>>> 
>>>>>>>>>>> or 
>>>>>>>>>>> 
>>>>>>>>>>> scan_bigin_src = TRIG_TIMER
>>>>>>>>>> 
>>>>>>>>>> I think you are right. If the sampling clock comes from another
>>>>>>>>>> subdevice, TRIG_EXT may not be the most appropriate constant. However,
>>>>>>>>>> the original comedi driver only expects TRIG_EXT even if... the
>>>>>>>>>> sampling signal is not external.
>>>>>>>>>> 
>>>>>>>>>> TRIG_TIMER does not seem suitable because it assumes an independant
>>>>>>>>>> sampling clock is available.  
>>>>>>>>>> 
>>>>>>>>>> And TRIG_FOLLOW may be the most appropriate one. We should modify the
>>>>>>>>>> driver so that TRIG_FOLLOW is used if the analog sampling clock is
>>>>>>>>>> chosen.
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> if I try any of these sources, I get an error -22, and dmesg reports:
>>>>>>>>>>> 
>>>>>>>>>>> [195882.321300] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> For me, the command interface is an empty shell because the various
>>>>>>>>>> parameters (start_src, scan_begin_src, ...) and the values (TRIG_*)
>>>>>>>>>> are imposed. And, on the other side, the driver is fully in charge of
>>>>>>>>>> the command structure as it is. So, the comedi command imposes a
>>>>>>>>>> communication method but does not ease the driver's task of managing
>>>>>>>>>> it (errors checking, translation, etc.)
>>>>>>>>>> 
>>>>>>>>>> And, in our case: DIO, we may conclude that this imposed API does not
>>>>>>>>>> fit well: in scan_begin_arg, we have to pass an index which is
>>>>>>>>>> supposed to correspond to some sampling clock (which is specific to a
>>>>>>>>>> board). Then, we use a generic interface with board-specific
>>>>>>>>>> arguments.
>>>>>>>>>> 
>>>>>>>>>> So, to sum up, I understand your point: the way we control the driver
>>>>>>>>>> may not always be the most appropriate one. But, we inherited from
>>>>>>>>>> comedi both the interface and the drivers. 
>>>>>>>>>> 
>>>>>>>>>> On my side, I am working on trying to implement (as a background task)
>>>>>>>>>> a generic interface a little bit more based on discovery (query /
>>>>>>>>>> enum) that would render the command interface obsolete. Unfortunately,
>>>>>>>>>> I have nothing interesting to show yet.
>>>>>>>>>> 
>>>>>>>>>>> Best wishes,
>>>>>>>>>>> 
>>>>>>>>>>> -STefan
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> Xenomai-core mailing list
>>>>>>>>> Xenomai-core@domain.hid
>>>>>>>>> https://mail.gna.org/listinfo/xenomai-core
>>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> Alexis.
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Xenomai-core mailing list
>>>>>> Xenomai-core@domain.hid
>>>>>> https://mail.gna.org/listinfo/xenomai-core
>>>>> 
>>>> 
>>>> -- 
>>>> Alexis.
>>> 
>> 
>> -- 
>> Alexis.
> 
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] analogy - experimental branch

[Alexis Berlemont]

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 0xffffffff and 0x0 values to the devices to generate a square wave on the oscilloscope. I cannot see anything of the square wave executed.
> >>> 
> >> 
> >> At last, it comes!!!
> >> 
> >> Thanks to your test program and your help, I think I have fixed this
> >> bug. Could you clone my git repository (branch analogy), and give it a
> >> try with your own test program.
> >> 
> >> There was a bug in the mite configuration which explained why the
> >> wrong data were sent to the DIO subdevice. That was also the reason
> >> why no interrupt came from the mite.
> >> 
> >>> Best wishes,
> >>> 
> >>> -Stefan
> >>> 
> >>> 
> >>> On Jul 19, 2010, at 15:01, Alexis Berlemont wrote:
> >>> 
> >>>> Hi,
> >>>> 
> >>>> Sorry for answering late. 
> >>>> 
> >>>> Stefan Schaal wrote:
> >>>>> Hi Alexis,
> >>>>> 
> >>>>> I managed to port some of the Comedi examples to Analogy. In particular, I could configure one of my counter subdevices to become a high frequency clock, following the gpct_pulse_generator.c example. I routed the output of the clock to my PFI0 pin, and could visualize the signal on an oscilloscope. Thus, I know have the clock I need to trigger CMD-based DIO, as you suggested. (I will post some sample code of this in the near future after all is cleaned up).
> >>>>> 
> >>>>> Next, I went back to cmd_bits.c and try to make it work on my NI6259 board. For scan_begin_src=TRIG_EXT   I need to choose scan_begin_arg = 28 (which is kCDO_Update_Source_SelectG0_Out in the NI documentation, and NI_CDIO_SCAN_BEGIN_SRC_G0_OUT in the comedi.h file).
> >>>>> 
> >>>>> When running cmd_bits.c in this way and monitoring the DO channels on an oscilloscope, the DO switches to HIGH when the acquisition is triggered (i.e., the value of the first element in the FIFO), but the FIFO is not processed any further, i.e., not emptied. If I DO NOT run the counter-clock above, the DO does not even switch to HIGH. I also checked whether 28 is the right value for scan_begin_arg by trying a wide range of values, but only for scan_begin_arg = 28 I get the DO bit switched to HIGH at the beginning of the acquisition.
> >>>>> 
> >>>>> In Comedi, the cmd.flags is set to CMDF_WRITE for such externally triggered acquisitions, which I tried, but it did not help.
> >>>>> 
> >>>>> Thus, it appears that I still have a problem in processing the FIFO, despite it appears that all other things are now correctly connected (Comedi has an example do_waveform.c, which is pretty much what I try to use for testing in my own code).
> >>>>> 
> >>>>> Would you have any thoughts on what might go wrong? It looks like we are just a tiny bit away from succeeding with cmd_bits.c on my board.
> >>>>> 
> >>>> 
> >>>> I had time to have a look at your problem. Unfortunately, I do not
> >>>> have any solution. I just have some questions you may find stupid:
> >>>> 
> >>>> - Did you try to invert the sample clock polarity by setting the flag
> >>>> CR_INVERT in the command field scan_begin_arg?
> >>>> - Which frequencies did you generate with the counter subdevice? Even
> >>>> the lowest one did nothing (Something like 10Hz)?
> >>>> - Did you try to send 0 with cmd_bits ? Just to check that the DO stay
> >>>> to LOW, which would mean that the values (or at least the first one)
> >>>> are properly loaded into the device.
> >>>> - So far, cmd_bits always sends the same value (the one you passed as
> >>>> argument); we should modify it so that the complement value is
> >>>> written every two samples. That would allow us to physically check
> >>>> how many samples are "played" by the DO. 
> >>>> 
> >>>>> Best wishes,
> >>>>> 
> >>>>> -Stefan
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> On Jul 14, 2010, at 17:46, Stefan Schaal wrote:
> >>>>> 
> >>>>>> Hi Alexis,
> >>>>>> 
> >>>>>> in the Comedi examples (http://www.comedi.org/download/comedilib-0.8.1.tar.gz, the do_waveform.c example), they suggest to use a general purpose counter as clocking input to a cmd-based DIO acquisition. This seems to be the signal "kCDO_Update_Source_SelectG0_Out            = 28" from the enum you found in the NI documentation.
> >>>>>> 
> >>>>>> For this purpose, the counter needs to be configured and triggered. Does Analogy already have the functionality to do such operations? The Comedi libraries have an example for this, too, in gpct_pulse_generator.c, just that this example uses a variety of function calls that I cannot directly map to the current Analogy functionality.
> >>>>>> 
> >>>>>> Or, do you happen to know whether there is another, easier to access, clock source?
> >>>>>> 
> >>>>>> Best wishes,
> >>>>>> 
> >>>>>> -Stefan
> >>>>>> 
> >>>>>> 
> >>>>>> On Jul 14, 2010, at 14:03, Alexis Berlemont wrote:
> >>>>>> 
> >>>>>>> Stefan Schaal wrote:
> >>>>>>>> Hi Alexis,
> >>>>>>>> 
> >>>>>>>> maybe it is more useful to mention what I actually want to achieve with DIO on my NI6259.  My DIO communication involves a series of interactions with another board to collect sensory data from a robot, and to send out commands to this board. For instance, to read one of the sensors, a sequence of DIO values need to be written to tell the board to send the data. I programmed this initially with synchronous instructions using a4l_sync_dio(), but this turns out to be too slow. Thus, the hope is to use commands, i.e., fill the FIFO with the sequence of values which I need to execute, and then use asynchronous DIO to obtain much higher speed of communicating the values in the FIFO.
> >>>>>>>> 
> >>>>>>>> Thus, what I essentially try to do is to put about 10-20 scans in the FIFO, and then write the FIFO as fast as possible to my NI6259 DIO subdevice.
> >>>>>>>> 
> >>>>>>>> Would you have any ideas how to do this fast writing of the scans in the FIFO with the current analogy functionality?
> >>>>>>>> 
> >>>>>>> Right now, I don't know. I think your idea of using DIO commands may
> >>>>>>> be suitable (I don't know your timing constraints). So what not
> >>>>>>> proceeding ?
> >>>>>>> 
> >>>>>>>> Thanks a lot!
> >>>>>>>> 
> >>>>>>>> -Stefan
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> On Jul 12, 2010, at 22:51, Stefan Schaal wrote:
> >>>>>>>> 
> >>>>>>>>> Hi Alexis,
> >>>>>>>>> 
> >>>>>>>>> thanks a lot for the explanations. One item I am confused about is that you write that TRIG_TIMER is not suitable for DIO, but in cmd_write.c in your sample code, it is used for the analog write without problems. Wouldn't one be able to just use the same clock source for DIO as in analogue I/O?
> >>>>>>>>> 
> >>>>>>>>> Best wishes,
> >>>>>>>>> 
> >>>>>>>>> -Stefan
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> On Jul 12, 2010, at 15:29, Alexis Berlemont wrote:
> >>>>>>>>> 
> >>>>>>>>>> Hi,
> >>>>>>>>>> 
> >>>>>>>>>> Stefan Schaal wrote:
> >>>>>>>>>>> Hi Alexis,
> >>>>>>>>>>> 
> >>>>>>>>>>> I guess I slowly understand that my clocking signal connected to
> >>>>>>>>>>> scan_begin_arg has to come from an external DIO input, if
> >>>>>>>>>>> scan_bigin_src = TRIG_EXT, and that the insn instruction is still
> >>>>>>>>>>> needed to trigger the entire acquisition. 
> >>>>>>>>>> 
> >>>>>>>>>> Yes. The trigger instruction is needed so as to start the whole
> >>>>>>>>>> acquisition (which is composed of many scans). A periodic external
> >>>>>>>>>> signal is needed so as to trigger each scan.
> >>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> Alternatively, would it be possible to use the internal clocking signals like 
> >>>>>>>>>>> 
> >>>>>>>>>>> scan_bigin_src = TRIG_FOLLOW
> >>>>>>>>>>> 
> >>>>>>>>>>> or 
> >>>>>>>>>>> 
> >>>>>>>>>>> scan_bigin_src = TRIG_TIMER
> >>>>>>>>>> 
> >>>>>>>>>> I think you are right. If the sampling clock comes from another
> >>>>>>>>>> subdevice, TRIG_EXT may not be the most appropriate constant. However,
> >>>>>>>>>> the original comedi driver only expects TRIG_EXT even if... the
> >>>>>>>>>> sampling signal is not external.
> >>>>>>>>>> 
> >>>>>>>>>> TRIG_TIMER does not seem suitable because it assumes an independant
> >>>>>>>>>> sampling clock is available.  
> >>>>>>>>>> 
> >>>>>>>>>> And TRIG_FOLLOW may be the most appropriate one. We should modify the
> >>>>>>>>>> driver so that TRIG_FOLLOW is used if the analog sampling clock is
> >>>>>>>>>> chosen.
> >>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> if I try any of these sources, I get an error -22, and dmesg reports:
> >>>>>>>>>>> 
> >>>>>>>>>>> [195882.321300] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported
> >>>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> For me, the command interface is an empty shell because the various
> >>>>>>>>>> parameters (start_src, scan_begin_src, ...) and the values (TRIG_*)
> >>>>>>>>>> are imposed. And, on the other side, the driver is fully in charge of
> >>>>>>>>>> the command structure as it is. So, the comedi command imposes a
> >>>>>>>>>> communication method but does not ease the driver's task of managing
> >>>>>>>>>> it (errors checking, translation, etc.)
> >>>>>>>>>> 
> >>>>>>>>>> And, in our case: DIO, we may conclude that this imposed API does not
> >>>>>>>>>> fit well: in scan_begin_arg, we have to pass an index which is
> >>>>>>>>>> supposed to correspond to some sampling clock (which is specific to a
> >>>>>>>>>> board). Then, we use a generic interface with board-specific
> >>>>>>>>>> arguments.
> >>>>>>>>>> 
> >>>>>>>>>> So, to sum up, I understand your point: the way we control the driver
> >>>>>>>>>> may not always be the most appropriate one. But, we inherited from
> >>>>>>>>>> comedi both the interface and the drivers. 
> >>>>>>>>>> 
> >>>>>>>>>> On my side, I am working on trying to implement (as a background task)
> >>>>>>>>>> a generic interface a little bit more based on discovery (query /
> >>>>>>>>>> enum) that would render the command interface obsolete. Unfortunately,
> >>>>>>>>>> I have nothing interesting to show yet.
> >>>>>>>>>> 
> >>>>>>>>>>> Best wishes,
> >>>>>>>>>>> 
> >>>>>>>>>>> -STefan
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Xenomai-core mailing list
> >>>>>>>>> Xenomai-core@domain.hid
> >>>>>>>>> https://mail.gna.org/listinfo/xenomai-core
> >>>>>>>> 
> >>>>>>> 
> >>>>>>> -- 
> >>>>>>> Alexis.
> >>>>>> 
> >>>>>> 
> >>>>>> _______________________________________________
> >>>>>> Xenomai-core mailing list
> >>>>>> Xenomai-core@domain.hid
> >>>>>> https://mail.gna.org/listinfo/xenomai-core
> >>>>> 
> >>>> 
> >>>> -- 
> >>>> Alexis.
> >>> 
> >> 
> >> -- 
> >> Alexis.
> > 
> > 
> > _______________________________________________
> > Xenomai-core mailing list
> > Xenomai-core@domain.hid
> > https://mail.gna.org/listinfo/xenomai-core
> 

-- 
Alexis.

Re: [Xenomai-core] analogy - experimental branch

[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 0xffffffff and 0x0 values to the devices to generate a square wave on the oscilloscope. I cannot see anything of the square wave executed.
>>>>> 
>>>> 
>>>> At last, it comes!!!
>>>> 
>>>> Thanks to your test program and your help, I think I have fixed this
>>>> bug. Could you clone my git repository (branch analogy), and give it a
>>>> try with your own test program.
>>>> 
>>>> There was a bug in the mite configuration which explained why the
>>>> wrong data were sent to the DIO subdevice. That was also the reason
>>>> why no interrupt came from the mite.
>>>> 
>>>>> Best wishes,
>>>>> 
>>>>> -Stefan
>>>>> 
>>>>> 
>>>>> On Jul 19, 2010, at 15:01, Alexis Berlemont wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Sorry for answering late. 
>>>>>> 
>>>>>> Stefan Schaal wrote:
>>>>>>> Hi Alexis,
>>>>>>> 
>>>>>>> I managed to port some of the Comedi examples to Analogy. In particular, I could configure one of my counter subdevices to become a high frequency clock, following the gpct_pulse_generator.c example. I routed the output of the clock to my PFI0 pin, and could visualize the signal on an oscilloscope. Thus, I know have the clock I need to trigger CMD-based DIO, as you suggested. (I will post some sample code of this in the near future after all is cleaned up).
>>>>>>> 
>>>>>>> Next, I went back to cmd_bits.c and try to make it work on my NI6259 board. For scan_begin_src=TRIG_EXT   I need to choose scan_begin_arg = 28 (which is kCDO_Update_Source_SelectG0_Out in the NI documentation, and NI_CDIO_SCAN_BEGIN_SRC_G0_OUT in the comedi.h file).
>>>>>>> 
>>>>>>> When running cmd_bits.c in this way and monitoring the DO channels on an oscilloscope, the DO switches to HIGH when the acquisition is triggered (i.e., the value of the first element in the FIFO), but the FIFO is not processed any further, i.e., not emptied. If I DO NOT run the counter-clock above, the DO does not even switch to HIGH. I also checked whether 28 is the right value for scan_begin_arg by trying a wide range of values, but only for scan_begin_arg = 28 I get the DO bit switched to HIGH at the beginning of the acquisition.
>>>>>>> 
>>>>>>> In Comedi, the cmd.flags is set to CMDF_WRITE for such externally triggered acquisitions, which I tried, but it did not help.
>>>>>>> 
>>>>>>> Thus, it appears that I still have a problem in processing the FIFO, despite it appears that all other things are now correctly connected (Comedi has an example do_waveform.c, which is pretty much what I try to use for testing in my own code).
>>>>>>> 
>>>>>>> Would you have any thoughts on what might go wrong? It looks like we are just a tiny bit away from succeeding with cmd_bits.c on my board.
>>>>>>> 
>>>>>> 
>>>>>> I had time to have a look at your problem. Unfortunately, I do not
>>>>>> have any solution. I just have some questions you may find stupid:
>>>>>> 
>>>>>> - Did you try to invert the sample clock polarity by setting the flag
>>>>>> CR_INVERT in the command field scan_begin_arg?
>>>>>> - Which frequencies did you generate with the counter subdevice? Even
>>>>>> the lowest one did nothing (Something like 10Hz)?
>>>>>> - Did you try to send 0 with cmd_bits ? Just to check that the DO stay
>>>>>> to LOW, which would mean that the values (or at least the first one)
>>>>>> are properly loaded into the device.
>>>>>> - So far, cmd_bits always sends the same value (the one you passed as
>>>>>> argument); we should modify it so that the complement value is
>>>>>> written every two samples. That would allow us to physically check
>>>>>> how many samples are "played" by the DO. 
>>>>>> 
>>>>>>> Best wishes,
>>>>>>> 
>>>>>>> -Stefan
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Jul 14, 2010, at 17:46, Stefan Schaal wrote:
>>>>>>> 
>>>>>>>> Hi Alexis,
>>>>>>>> 
>>>>>>>> in the Comedi examples (http://www.comedi.org/download/comedilib-0.8.1.tar.gz, the do_waveform.c example), they suggest to use a general purpose counter as clocking input to a cmd-based DIO acquisition. This seems to be the signal "kCDO_Update_Source_SelectG0_Out            = 28" from the enum you found in the NI documentation.
>>>>>>>> 
>>>>>>>> For this purpose, the counter needs to be configured and triggered. Does Analogy already have the functionality to do such operations? The Comedi libraries have an example for this, too, in gpct_pulse_generator.c, just that this example uses a variety of function calls that I cannot directly map to the current Analogy functionality.
>>>>>>>> 
>>>>>>>> Or, do you happen to know whether there is another, easier to access, clock source?
>>>>>>>> 
>>>>>>>> Best wishes,
>>>>>>>> 
>>>>>>>> -Stefan
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Jul 14, 2010, at 14:03, Alexis Berlemont wrote:
>>>>>>>> 
>>>>>>>>> Stefan Schaal wrote:
>>>>>>>>>> Hi Alexis,
>>>>>>>>>> 
>>>>>>>>>> maybe it is more useful to mention what I actually want to achieve with DIO on my NI6259.  My DIO communication involves a series of interactions with another board to collect sensory data from a robot, and to send out commands to this board. For instance, to read one of the sensors, a sequence of DIO values need to be written to tell the board to send the data. I programmed this initially with synchronous instructions using a4l_sync_dio(), but this turns out to be too slow. Thus, the hope is to use commands, i.e., fill the FIFO with the sequence of values which I need to execute, and then use asynchronous DIO to obtain much higher speed of communicating the values in the FIFO.
>>>>>>>>>> 
>>>>>>>>>> Thus, what I essentially try to do is to put about 10-20 scans in the FIFO, and then write the FIFO as fast as possible to my NI6259 DIO subdevice.
>>>>>>>>>> 
>>>>>>>>>> Would you have any ideas how to do this fast writing of the scans in the FIFO with the current analogy functionality?
>>>>>>>>>> 
>>>>>>>>> Right now, I don't know. I think your idea of using DIO commands may
>>>>>>>>> be suitable (I don't know your timing constraints). So what not
>>>>>>>>> proceeding ?
>>>>>>>>> 
>>>>>>>>>> Thanks a lot!
>>>>>>>>>> 
>>>>>>>>>> -Stefan
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Jul 12, 2010, at 22:51, Stefan Schaal wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hi Alexis,
>>>>>>>>>>> 
>>>>>>>>>>> thanks a lot for the explanations. One item I am confused about is that you write that TRIG_TIMER is not suitable for DIO, but in cmd_write.c in your sample code, it is used for the analog write without problems. Wouldn't one be able to just use the same clock source for DIO as in analogue I/O?
>>>>>>>>>>> 
>>>>>>>>>>> Best wishes,
>>>>>>>>>>> 
>>>>>>>>>>> -Stefan
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Jul 12, 2010, at 15:29, Alexis Berlemont wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> 
>>>>>>>>>>>> Stefan Schaal wrote:
>>>>>>>>>>>>> Hi Alexis,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I guess I slowly understand that my clocking signal connected to
>>>>>>>>>>>>> scan_begin_arg has to come from an external DIO input, if
>>>>>>>>>>>>> scan_bigin_src = TRIG_EXT, and that the insn instruction is still
>>>>>>>>>>>>> needed to trigger the entire acquisition. 
>>>>>>>>>>>> 
>>>>>>>>>>>> Yes. The trigger instruction is needed so as to start the whole
>>>>>>>>>>>> acquisition (which is composed of many scans). A periodic external
>>>>>>>>>>>> signal is needed so as to trigger each scan.
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Alternatively, would it be possible to use the internal clocking signals like 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> scan_bigin_src = TRIG_FOLLOW
>>>>>>>>>>>>> 
>>>>>>>>>>>>> or 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> scan_bigin_src = TRIG_TIMER
>>>>>>>>>>>> 
>>>>>>>>>>>> I think you are right. If the sampling clock comes from another
>>>>>>>>>>>> subdevice, TRIG_EXT may not be the most appropriate constant. However,
>>>>>>>>>>>> the original comedi driver only expects TRIG_EXT even if... the
>>>>>>>>>>>> sampling signal is not external.
>>>>>>>>>>>> 
>>>>>>>>>>>> TRIG_TIMER does not seem suitable because it assumes an independant
>>>>>>>>>>>> sampling clock is available.  
>>>>>>>>>>>> 
>>>>>>>>>>>> And TRIG_FOLLOW may be the most appropriate one. We should modify the
>>>>>>>>>>>> driver so that TRIG_FOLLOW is used if the analog sampling clock is
>>>>>>>>>>>> chosen.
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> if I try any of these sources, I get an error -22, and dmesg reports:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [195882.321300] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> For me, the command interface is an empty shell because the various
>>>>>>>>>>>> parameters (start_src, scan_begin_src, ...) and the values (TRIG_*)
>>>>>>>>>>>> are imposed. And, on the other side, the driver is fully in charge of
>>>>>>>>>>>> the command structure as it is. So, the comedi command imposes a
>>>>>>>>>>>> communication method but does not ease the driver's task of managing
>>>>>>>>>>>> it (errors checking, translation, etc.)
>>>>>>>>>>>> 
>>>>>>>>>>>> And, in our case: DIO, we may conclude that this imposed API does not
>>>>>>>>>>>> fit well: in scan_begin_arg, we have to pass an index which is
>>>>>>>>>>>> supposed to correspond to some sampling clock (which is specific to a
>>>>>>>>>>>> board). Then, we use a generic interface with board-specific
>>>>>>>>>>>> arguments.
>>>>>>>>>>>> 
>>>>>>>>>>>> So, to sum up, I understand your point: the way we control the driver
>>>>>>>>>>>> may not always be the most appropriate one. But, we inherited from
>>>>>>>>>>>> comedi both the interface and the drivers. 
>>>>>>>>>>>> 
>>>>>>>>>>>> On my side, I am working on trying to implement (as a background task)
>>>>>>>>>>>> a generic interface a little bit more based on discovery (query /
>>>>>>>>>>>> enum) that would render the command interface obsolete. Unfortunately,
>>>>>>>>>>>> I have nothing interesting to show yet.
>>>>>>>>>>>> 
>>>>>>>>>>>>> Best wishes,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -STefan
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Xenomai-core mailing list
>>>>>>>>>>> Xenomai-core@domain.hid
>>>>>>>>>>> https://mail.gna.org/listinfo/xenomai-core
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -- 
>>>>>>>>> Alexis.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Xenomai-core mailing list
>>>>>>>> Xenomai-core@domain.hid
>>>>>>>> https://mail.gna.org/listinfo/xenomai-core
>>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Alexis.
>>>>> 
>>>> 
>>>> -- 
>>>> Alexis.
>>> 
>>> 
>>> _______________________________________________
>>> Xenomai-core mailing list
>>> Xenomai-core@domain.hid
>>> https://mail.gna.org/listinfo/xenomai-core
>> 
> 
> -- 
> Alexis.

Re: [Xenomai-core] analogy - experimental branch

[Alexis Berlemont]

Hi,

On Wed, Sep 8, 2010 at 4:30 PM, Stefan Schaal <sschaal@domain.hid> wrote:
> Hi Alexis,
>
>   sorry for my late reply -- I was traveling.
>
> Essentially, in my DIO communication, I need to switch some DIO channels from READ to WRITE after several scans, and than back. This is why the stop argument would be very useful.
>
> Also, currently in the cmd_bits test program, one gets a lot messages from dmesg:
>
> [1325379.753432] Analogy: MITE: DMA underrun
>
> which comes, I guess, from not continuously filling the FIFO buffer with data.
>
> I will try to look through comedi and the NI documentation what register might have the counting information.

The needed documentation is the register level programing manual for M
series. The registers related with asynchronous DIO acquisition are
not defined in the DAQ documentation.

>
> Best wishes,
>
> -Stefan
>
>

Alexis.

> On Sep 4, 2010, at 14:45, Alexis Berlemont wrote:
>
>> Hi,
>>
>> Stefan Schaal wrote:
>>> Hi Alexis,
>>>
>>> we are making great progress with our work. One issue that came up is whether it would be possible to add
>>>
>>>   .stop_src = TRIG_COUNT,
>>>   .stop_arg = n,
>>>
>>> in the command structure, i.e., that the command terminates after n scans. Currently, when I try this, dmesg tells me that this method is not supported.
>>>
>> I don't have the documentation of the CDIO registers; so, I dont' know
>> how to tell the subdevice to stop after having sent a specified amount
>> of data.
>>
>> However, analogy stops an acquisition when the stop_arg of the command
>> structure has been reached. We would be able to cancel the acquisition
>> after having sent _at_ _least_ the specified amount but we would not
>> be able to accurately send the specified amount of data.
>>
>> I think we should firstly get the proper documentation. I will try to
>> have a look at the open source code delivered by NI.
>>
>>> Best wishes,
>>>
>>> -Stefan
>>>
>>>
>>>
>>>
>>> On Aug 23, 2010, at 23:49, Stefan Schaal wrote:
>>>
>>>> Hi Alexis,
>>>>
>>>> amazing progress!! And it works! I just ran my test program on our NI6259 board and got perfect performance. I quickly tested 5MHz  DIO rate, and it appeared to work fine according to the square waves on the oscilloscope.
>>>>
>>>> I will go back to developing our DAQ interface, and report back to the Xenomai list about performance.
>>>>
>>>> Thanks so much!!!!
>>>>
>>>> Best wishes,
>>>>
>>>> -Stefan
>>>>
>>>>
>>>> On Aug 23, 2010, at 16:09, Alexis Berlemont wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Stefan Schaal wrote:
>>>>>> Hi Alexis,
>>>>>>
>>>>>> as usually, we are more than grateful that you are willing to spend time on this issue. Here are answers to your questions:
>>>>>>
>>>>>> 1) I tried CR_INVERT -- no success
>>>>>> 2) I tried very slow frequencies like 10Hz in the counter clock (which is nicely visualized on my oscilloscope) -- no success
>>>>>> 3) I tried to send a 0 with cmd_bits -- and interestingly, this ALSO takes my DIO line high (sorry, I thought I had tested this before). This would indicate that we do not access the FIFO at all?
>>>>>> 4) I have my own test program to send alternating 0xffffffff and 0x0 values to the devices to generate a square wave on the oscilloscope. I cannot see anything of the square wave executed.
>>>>>>
>>>>>
>>>>> At last, it comes!!!
>>>>>
>>>>> Thanks to your test program and your help, I think I have fixed this
>>>>> bug. Could you clone my git repository (branch analogy), and give it a
>>>>> try with your own test program.
>>>>>
>>>>> There was a bug in the mite configuration which explained why the
>>>>> wrong data were sent to the DIO subdevice. That was also the reason
>>>>> why no interrupt came from the mite.
>>>>>
>>>>>> Best wishes,
>>>>>>
>>>>>> -Stefan
>>>>>>
>>>>>>
>>>>>> On Jul 19, 2010, at 15:01, Alexis Berlemont wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Sorry for answering late.
>>>>>>>
>>>>>>> Stefan Schaal wrote:
>>>>>>>> Hi Alexis,
>>>>>>>>
>>>>>>>> I managed to port some of the Comedi examples to Analogy. In particular, I could configure one of my counter subdevices to become a high frequency clock, following the gpct_pulse_generator.c example. I routed the output of the clock to my PFI0 pin, and could visualize the signal on an oscilloscope. Thus, I know have the clock I need to trigger CMD-based DIO, as you suggested. (I will post some sample code of this in the near future after all is cleaned up).
>>>>>>>>
>>>>>>>> Next, I went back to cmd_bits.c and try to make it work on my NI6259 board. For scan_begin_src=TRIG_EXT   I need to choose scan_begin_arg = 28 (which is kCDO_Update_Source_SelectG0_Out in the NI documentation, and NI_CDIO_SCAN_BEGIN_SRC_G0_OUT in the comedi.h file).
>>>>>>>>
>>>>>>>> When running cmd_bits.c in this way and monitoring the DO channels on an oscilloscope, the DO switches to HIGH when the acquisition is triggered (i.e., the value of the first element in the FIFO), but the FIFO is not processed any further, i.e., not emptied. If I DO NOT run the counter-clock above, the DO does not even switch to HIGH. I also checked whether 28 is the right value for scan_begin_arg by trying a wide range of values, but only for scan_begin_arg = 28 I get the DO bit switched to HIGH at the beginning of the acquisition.
>>>>>>>>
>>>>>>>> In Comedi, the cmd.flags is set to CMDF_WRITE for such externally triggered acquisitions, which I tried, but it did not help.
>>>>>>>>
>>>>>>>> Thus, it appears that I still have a problem in processing the FIFO, despite it appears that all other things are now correctly connected (Comedi has an example do_waveform.c, which is pretty much what I try to use for testing in my own code).
>>>>>>>>
>>>>>>>> Would you have any thoughts on what might go wrong? It looks like we are just a tiny bit away from succeeding with cmd_bits.c on my board.
>>>>>>>>
>>>>>>>
>>>>>>> I had time to have a look at your problem. Unfortunately, I do not
>>>>>>> have any solution. I just have some questions you may find stupid:
>>>>>>>
>>>>>>> - Did you try to invert the sample clock polarity by setting the flag
>>>>>>> CR_INVERT in the command field scan_begin_arg?
>>>>>>> - Which frequencies did you generate with the counter subdevice? Even
>>>>>>> the lowest one did nothing (Something like 10Hz)?
>>>>>>> - Did you try to send 0 with cmd_bits ? Just to check that the DO stay
>>>>>>> to LOW, which would mean that the values (or at least the first one)
>>>>>>> are properly loaded into the device.
>>>>>>> - So far, cmd_bits always sends the same value (the one you passed as
>>>>>>> argument); we should modify it so that the complement value is
>>>>>>> written every two samples. That would allow us to physically check
>>>>>>> how many samples are "played" by the DO.
>>>>>>>
>>>>>>>> Best wishes,
>>>>>>>>
>>>>>>>> -Stefan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jul 14, 2010, at 17:46, Stefan Schaal wrote:
>>>>>>>>
>>>>>>>>> Hi Alexis,
>>>>>>>>>
>>>>>>>>> in the Comedi examples (http://www.comedi.org/download/comedilib-0.8.1.tar.gz, the do_waveform.c example), they suggest to use a general purpose counter as clocking input to a cmd-based DIO acquisition. This seems to be the signal "kCDO_Update_Source_SelectG0_Out            = 28" from the enum you found in the NI documentation.
>>>>>>>>>
>>>>>>>>> For this purpose, the counter needs to be configured and triggered. Does Analogy already have the functionality to do such operations? The Comedi libraries have an example for this, too, in gpct_pulse_generator.c, just that this example uses a variety of function calls that I cannot directly map to the current Analogy functionality.
>>>>>>>>>
>>>>>>>>> Or, do you happen to know whether there is another, easier to access, clock source?
>>>>>>>>>
>>>>>>>>> Best wishes,
>>>>>>>>>
>>>>>>>>> -Stefan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Jul 14, 2010, at 14:03, Alexis Berlemont wrote:
>>>>>>>>>
>>>>>>>>>> Stefan Schaal wrote:
>>>>>>>>>>> Hi Alexis,
>>>>>>>>>>>
>>>>>>>>>>> maybe it is more useful to mention what I actually want to achieve with DIO on my NI6259.  My DIO communication involves a series of interactions with another board to collect sensory data from a robot, and to send out commands to this board. For instance, to read one of the sensors, a sequence of DIO values need to be written to tell the board to send the data. I programmed this initially with synchronous instructions using a4l_sync_dio(), but this turns out to be too slow. Thus, the hope is to use commands, i.e., fill the FIFO with the sequence of values which I need to execute, and then use asynchronous DIO to obtain much higher speed of communicating the values in the FIFO.
>>>>>>>>>>>
>>>>>>>>>>> Thus, what I essentially try to do is to put about 10-20 scans in the FIFO, and then write the FIFO as fast as possible to my NI6259 DIO subdevice.
>>>>>>>>>>>
>>>>>>>>>>> Would you have any ideas how to do this fast writing of the scans in the FIFO with the current analogy functionality?
>>>>>>>>>>>
>>>>>>>>>> Right now, I don't know. I think your idea of using DIO commands may
>>>>>>>>>> be suitable (I don't know your timing constraints). So what not
>>>>>>>>>> proceeding ?
>>>>>>>>>>
>>>>>>>>>>> Thanks a lot!
>>>>>>>>>>>
>>>>>>>>>>> -Stefan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Jul 12, 2010, at 22:51, Stefan Schaal wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Alexis,
>>>>>>>>>>>>
>>>>>>>>>>>> thanks a lot for the explanations. One item I am confused about is that you write that TRIG_TIMER is not suitable for DIO, but in cmd_write.c in your sample code, it is used for the analog write without problems. Wouldn't one be able to just use the same clock source for DIO as in analogue I/O?
>>>>>>>>>>>>
>>>>>>>>>>>> Best wishes,
>>>>>>>>>>>>
>>>>>>>>>>>> -Stefan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Jul 12, 2010, at 15:29, Alexis Berlemont wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Stefan Schaal wrote:
>>>>>>>>>>>>>> Hi Alexis,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I guess I slowly understand that my clocking signal connected to
>>>>>>>>>>>>>> scan_begin_arg has to come from an external DIO input, if
>>>>>>>>>>>>>> scan_bigin_src = TRIG_EXT, and that the insn instruction is still
>>>>>>>>>>>>>> needed to trigger the entire acquisition.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes. The trigger instruction is needed so as to start the whole
>>>>>>>>>>>>> acquisition (which is composed of many scans). A periodic external
>>>>>>>>>>>>> signal is needed so as to trigger each scan.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Alternatively, would it be possible to use the internal clocking signals like
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> scan_bigin_src = TRIG_FOLLOW
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> scan_bigin_src = TRIG_TIMER
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think you are right. If the sampling clock comes from another
>>>>>>>>>>>>> subdevice, TRIG_EXT may not be the most appropriate constant. However,
>>>>>>>>>>>>> the original comedi driver only expects TRIG_EXT even if... the
>>>>>>>>>>>>> sampling signal is not external.
>>>>>>>>>>>>>
>>>>>>>>>>>>> TRIG_TIMER does not seem suitable because it assumes an independant
>>>>>>>>>>>>> sampling clock is available.
>>>>>>>>>>>>>
>>>>>>>>>>>>> And TRIG_FOLLOW may be the most appropriate one. We should modify the
>>>>>>>>>>>>> driver so that TRIG_FOLLOW is used if the analog sampling clock is
>>>>>>>>>>>>> chosen.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> if I try any of these sources, I get an error -22, and dmesg reports:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [195882.321300] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> For me, the command interface is an empty shell because the various
>>>>>>>>>>>>> parameters (start_src, scan_begin_src, ...) and the values (TRIG_*)
>>>>>>>>>>>>> are imposed. And, on the other side, the driver is fully in charge of
>>>>>>>>>>>>> the command structure as it is. So, the comedi command imposes a
>>>>>>>>>>>>> communication method but does not ease the driver's task of managing
>>>>>>>>>>>>> it (errors checking, translation, etc.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> And, in our case: DIO, we may conclude that this imposed API does not
>>>>>>>>>>>>> fit well: in scan_begin_arg, we have to pass an index which is
>>>>>>>>>>>>> supposed to correspond to some sampling clock (which is specific to a
>>>>>>>>>>>>> board). Then, we use a generic interface with board-specific
>>>>>>>>>>>>> arguments.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, to sum up, I understand your point: the way we control the driver
>>>>>>>>>>>>> may not always be the most appropriate one. But, we inherited from
>>>>>>>>>>>>> comedi both the interface and the drivers.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On my side, I am working on trying to implement (as a background task)
>>>>>>>>>>>>> a generic interface a little bit more based on discovery (query /
>>>>>>>>>>>>> enum) that would render the command interface obsolete. Unfortunately,
>>>>>>>>>>>>> I have nothing interesting to show yet.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best wishes,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -STefan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Xenomai-core mailing list
>>>>>>>>>>>> Xenomai-core@domain.hid
>>>>>>>>>>>> https://mail.gna.org/listinfo/xenomai-core
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Alexis.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Xenomai-core mailing list
>>>>>>>>> Xenomai-core@domain.hid
>>>>>>>>> https://mail.gna.org/listinfo/xenomai-core
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Alexis.
>>>>>>
>>>>>
>>>>> --
>>>>> Alexis.
>>>>
>>>>
>>>> _______________________________________________
>>>> Xenomai-core mailing list
>>>> Xenomai-core@domain.hid
>>>> https://mail.gna.org/listinfo/xenomai-core
>>>
>>
>> --
>> Alexis.
>
>

Re: [Xenomai-core] analogy - experimental branch

[Stefan Schaal]

[-- Attachment #1: Type: text/plain, Size: 159 bytes --]

Hi Alexis,

  attached a document I found with NI. Look for the DIO_COMMAND section (at the end of the document. Is this useful?

Best wishes,

-Stefan

[-- Attachment #2: mseries_registermap.doc --]
[-- Type: application/msword, Size: 2551296 bytes --]

[-- Attachment #3: Type: text/plain, Size: 14756 bytes --]


On Sep 8, 2010, at 23:51, Alexis Berlemont wrote:

> Hi,
> 
> On Wed, Sep 8, 2010 at 4:30 PM, Stefan Schaal <sschaal@domain.hid> wrote:
>> Hi Alexis,
>> 
>>   sorry for my late reply -- I was traveling.
>> 
>> Essentially, in my DIO communication, I need to switch some DIO channels from READ to WRITE after several scans, and than back. This is why the stop argument would be very useful.
>> 
>> Also, currently in the cmd_bits test program, one gets a lot messages from dmesg:
>> 
>> [1325379.753432] Analogy: MITE: DMA underrun
>> 
>> which comes, I guess, from not continuously filling the FIFO buffer with data.
>> 
>> I will try to look through comedi and the NI documentation what register might have the counting information.
> 
> The needed documentation is the register level programing manual for M
> series. The registers related with asynchronous DIO acquisition are
> not defined in the DAQ documentation.
> 
>> 
>> Best wishes,
>> 
>> -Stefan
>> 
>> 
> 
> Alexis.
> 
>> On Sep 4, 2010, at 14:45, Alexis Berlemont wrote:
>> 
>>> Hi,
>>> 
>>> Stefan Schaal wrote:
>>>> Hi Alexis,
>>>> 
>>>> we are making great progress with our work. One issue that came up is whether it would be possible to add
>>>> 
>>>>   .stop_src = TRIG_COUNT,
>>>>   .stop_arg = n,
>>>> 
>>>> in the command structure, i.e., that the command terminates after n scans. Currently, when I try this, dmesg tells me that this method is not supported.
>>>> 
>>> I don't have the documentation of the CDIO registers; so, I dont' know
>>> how to tell the subdevice to stop after having sent a specified amount
>>> of data.
>>> 
>>> However, analogy stops an acquisition when the stop_arg of the command
>>> structure has been reached. We would be able to cancel the acquisition
>>> after having sent _at_ _least_ the specified amount but we would not
>>> be able to accurately send the specified amount of data.
>>> 
>>> I think we should firstly get the proper documentation. I will try to
>>> have a look at the open source code delivered by NI.
>>> 
>>>> Best wishes,
>>>> 
>>>> -Stefan
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Aug 23, 2010, at 23:49, Stefan Schaal wrote:
>>>> 
>>>>> Hi Alexis,
>>>>> 
>>>>> amazing progress!! And it works! I just ran my test program on our NI6259 board and got perfect performance. I quickly tested 5MHz  DIO rate, and it appeared to work fine according to the square waves on the oscilloscope.
>>>>> 
>>>>> I will go back to developing our DAQ interface, and report back to the Xenomai list about performance.
>>>>> 
>>>>> Thanks so much!!!!
>>>>> 
>>>>> Best wishes,
>>>>> 
>>>>> -Stefan
>>>>> 
>>>>> 
>>>>> On Aug 23, 2010, at 16:09, Alexis Berlemont wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Stefan Schaal wrote:
>>>>>>> Hi Alexis,
>>>>>>> 
>>>>>>> as usually, we are more than grateful that you are willing to spend time on this issue. Here are answers to your questions:
>>>>>>> 
>>>>>>> 1) I tried CR_INVERT -- no success
>>>>>>> 2) I tried very slow frequencies like 10Hz in the counter clock (which is nicely visualized on my oscilloscope) -- no success
>>>>>>> 3) I tried to send a 0 with cmd_bits -- and interestingly, this ALSO takes my DIO line high (sorry, I thought I had tested this before). This would indicate that we do not access the FIFO at all?
>>>>>>> 4) I have my own test program to send alternating 0xffffffff and 0x0 values to the devices to generate a square wave on the oscilloscope. I cannot see anything of the square wave executed.
>>>>>>> 
>>>>>> 
>>>>>> At last, it comes!!!
>>>>>> 
>>>>>> Thanks to your test program and your help, I think I have fixed this
>>>>>> bug. Could you clone my git repository (branch analogy), and give it a
>>>>>> try with your own test program.
>>>>>> 
>>>>>> There was a bug in the mite configuration which explained why the
>>>>>> wrong data were sent to the DIO subdevice. That was also the reason
>>>>>> why no interrupt came from the mite.
>>>>>> 
>>>>>>> Best wishes,
>>>>>>> 
>>>>>>> -Stefan
>>>>>>> 
>>>>>>> 
>>>>>>> On Jul 19, 2010, at 15:01, Alexis Berlemont wrote:
>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Sorry for answering late.
>>>>>>>> 
>>>>>>>> Stefan Schaal wrote:
>>>>>>>>> Hi Alexis,
>>>>>>>>> 
>>>>>>>>> I managed to port some of the Comedi examples to Analogy. In particular, I could configure one of my counter subdevices to become a high frequency clock, following the gpct_pulse_generator.c example. I routed the output of the clock to my PFI0 pin, and could visualize the signal on an oscilloscope. Thus, I know have the clock I need to trigger CMD-based DIO, as you suggested. (I will post some sample code of this in the near future after all is cleaned up).
>>>>>>>>> 
>>>>>>>>> Next, I went back to cmd_bits.c and try to make it work on my NI6259 board. For scan_begin_src=TRIG_EXT   I need to choose scan_begin_arg = 28 (which is kCDO_Update_Source_SelectG0_Out in the NI documentation, and NI_CDIO_SCAN_BEGIN_SRC_G0_OUT in the comedi.h file).
>>>>>>>>> 
>>>>>>>>> When running cmd_bits.c in this way and monitoring the DO channels on an oscilloscope, the DO switches to HIGH when the acquisition is triggered (i.e., the value of the first element in the FIFO), but the FIFO is not processed any further, i.e., not emptied. If I DO NOT run the counter-clock above, the DO does not even switch to HIGH. I also checked whether 28 is the right value for scan_begin_arg by trying a wide range of values, but only for scan_begin_arg = 28 I get the DO bit switched to HIGH at the beginning of the acquisition.
>>>>>>>>> 
>>>>>>>>> In Comedi, the cmd.flags is set to CMDF_WRITE for such externally triggered acquisitions, which I tried, but it did not help.
>>>>>>>>> 
>>>>>>>>> Thus, it appears that I still have a problem in processing the FIFO, despite it appears that all other things are now correctly connected (Comedi has an example do_waveform.c, which is pretty much what I try to use for testing in my own code).
>>>>>>>>> 
>>>>>>>>> Would you have any thoughts on what might go wrong? It looks like we are just a tiny bit away from succeeding with cmd_bits.c on my board.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> I had time to have a look at your problem. Unfortunately, I do not
>>>>>>>> have any solution. I just have some questions you may find stupid:
>>>>>>>> 
>>>>>>>> - Did you try to invert the sample clock polarity by setting the flag
>>>>>>>> CR_INVERT in the command field scan_begin_arg?
>>>>>>>> - Which frequencies did you generate with the counter subdevice? Even
>>>>>>>> the lowest one did nothing (Something like 10Hz)?
>>>>>>>> - Did you try to send 0 with cmd_bits ? Just to check that the DO stay
>>>>>>>> to LOW, which would mean that the values (or at least the first one)
>>>>>>>> are properly loaded into the device.
>>>>>>>> - So far, cmd_bits always sends the same value (the one you passed as
>>>>>>>> argument); we should modify it so that the complement value is
>>>>>>>> written every two samples. That would allow us to physically check
>>>>>>>> how many samples are "played" by the DO.
>>>>>>>> 
>>>>>>>>> Best wishes,
>>>>>>>>> 
>>>>>>>>> -Stefan
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Jul 14, 2010, at 17:46, Stefan Schaal wrote:
>>>>>>>>> 
>>>>>>>>>> Hi Alexis,
>>>>>>>>>> 
>>>>>>>>>> in the Comedi examples (http://www.comedi.org/download/comedilib-0.8.1.tar.gz, the do_waveform.c example), they suggest to use a general purpose counter as clocking input to a cmd-based DIO acquisition. This seems to be the signal "kCDO_Update_Source_SelectG0_Out            = 28" from the enum you found in the NI documentation.
>>>>>>>>>> 
>>>>>>>>>> For this purpose, the counter needs to be configured and triggered. Does Analogy already have the functionality to do such operations? The Comedi libraries have an example for this, too, in gpct_pulse_generator.c, just that this example uses a variety of function calls that I cannot directly map to the current Analogy functionality.
>>>>>>>>>> 
>>>>>>>>>> Or, do you happen to know whether there is another, easier to access, clock source?
>>>>>>>>>> 
>>>>>>>>>> Best wishes,
>>>>>>>>>> 
>>>>>>>>>> -Stefan
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Jul 14, 2010, at 14:03, Alexis Berlemont wrote:
>>>>>>>>>> 
>>>>>>>>>>> Stefan Schaal wrote:
>>>>>>>>>>>> Hi Alexis,
>>>>>>>>>>>> 
>>>>>>>>>>>> maybe it is more useful to mention what I actually want to achieve with DIO on my NI6259.  My DIO communication involves a series of interactions with another board to collect sensory data from a robot, and to send out commands to this board. For instance, to read one of the sensors, a sequence of DIO values need to be written to tell the board to send the data. I programmed this initially with synchronous instructions using a4l_sync_dio(), but this turns out to be too slow. Thus, the hope is to use commands, i.e., fill the FIFO with the sequence of values which I need to execute, and then use asynchronous DIO to obtain much higher speed of communicating the values in the FIFO.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thus, what I essentially try to do is to put about 10-20 scans in the FIFO, and then write the FIFO as fast as possible to my NI6259 DIO subdevice.
>>>>>>>>>>>> 
>>>>>>>>>>>> Would you have any ideas how to do this fast writing of the scans in the FIFO with the current analogy functionality?
>>>>>>>>>>>> 
>>>>>>>>>>> Right now, I don't know. I think your idea of using DIO commands may
>>>>>>>>>>> be suitable (I don't know your timing constraints). So what not
>>>>>>>>>>> proceeding ?
>>>>>>>>>>> 
>>>>>>>>>>>> Thanks a lot!
>>>>>>>>>>>> 
>>>>>>>>>>>> -Stefan
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Jul 12, 2010, at 22:51, Stefan Schaal wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi Alexis,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> thanks a lot for the explanations. One item I am confused about is that you write that TRIG_TIMER is not suitable for DIO, but in cmd_write.c in your sample code, it is used for the analog write without problems. Wouldn't one be able to just use the same clock source for DIO as in analogue I/O?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Best wishes,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -Stefan
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Jul 12, 2010, at 15:29, Alexis Berlemont wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Stefan Schaal wrote:
>>>>>>>>>>>>>>> Hi Alexis,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I guess I slowly understand that my clocking signal connected to
>>>>>>>>>>>>>>> scan_begin_arg has to come from an external DIO input, if
>>>>>>>>>>>>>>> scan_bigin_src = TRIG_EXT, and that the insn instruction is still
>>>>>>>>>>>>>>> needed to trigger the entire acquisition.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Yes. The trigger instruction is needed so as to start the whole
>>>>>>>>>>>>>> acquisition (which is composed of many scans). A periodic external
>>>>>>>>>>>>>> signal is needed so as to trigger each scan.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Alternatively, would it be possible to use the internal clocking signals like
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> scan_bigin_src = TRIG_FOLLOW
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> scan_bigin_src = TRIG_TIMER
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I think you are right. If the sampling clock comes from another
>>>>>>>>>>>>>> subdevice, TRIG_EXT may not be the most appropriate constant. However,
>>>>>>>>>>>>>> the original comedi driver only expects TRIG_EXT even if... the
>>>>>>>>>>>>>> sampling signal is not external.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> TRIG_TIMER does not seem suitable because it assumes an independant
>>>>>>>>>>>>>> sampling clock is available.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> And TRIG_FOLLOW may be the most appropriate one. We should modify the
>>>>>>>>>>>>>> driver so that TRIG_FOLLOW is used if the analog sampling clock is
>>>>>>>>>>>>>> chosen.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> if I try any of these sources, I get an error -22, and dmesg reports:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [195882.321300] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> For me, the command interface is an empty shell because the various
>>>>>>>>>>>>>> parameters (start_src, scan_begin_src, ...) and the values (TRIG_*)
>>>>>>>>>>>>>> are imposed. And, on the other side, the driver is fully in charge of
>>>>>>>>>>>>>> the command structure as it is. So, the comedi command imposes a
>>>>>>>>>>>>>> communication method but does not ease the driver's task of managing
>>>>>>>>>>>>>> it (errors checking, translation, etc.)
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> And, in our case: DIO, we may conclude that this imposed API does not
>>>>>>>>>>>>>> fit well: in scan_begin_arg, we have to pass an index which is
>>>>>>>>>>>>>> supposed to correspond to some sampling clock (which is specific to a
>>>>>>>>>>>>>> board). Then, we use a generic interface with board-specific
>>>>>>>>>>>>>> arguments.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> So, to sum up, I understand your point: the way we control the driver
>>>>>>>>>>>>>> may not always be the most appropriate one. But, we inherited from
>>>>>>>>>>>>>> comedi both the interface and the drivers.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On my side, I am working on trying to implement (as a background task)
>>>>>>>>>>>>>> a generic interface a little bit more based on discovery (query /
>>>>>>>>>>>>>> enum) that would render the command interface obsolete. Unfortunately,
>>>>>>>>>>>>>> I have nothing interesting to show yet.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Best wishes,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> -STefan
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Xenomai-core mailing list
>>>>>>>>>>>>> Xenomai-core@domain.hid
>>>>>>>>>>>>> https://mail.gna.org/listinfo/xenomai-core
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Alexis.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Xenomai-core mailing list
>>>>>>>>>> Xenomai-core@domain.hid
>>>>>>>>>> https://mail.gna.org/listinfo/xenomai-core
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Alexis.
>>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Alexis.
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Xenomai-core mailing list
>>>>> Xenomai-core@domain.hid
>>>>> https://mail.gna.org/listinfo/xenomai-core
>>>> 
>>> 
>>> --
>>> Alexis.
>> 
>> 

Re: [Xenomai-core] analogy - experimental branch

[Alexis Berlemont]

Stefan Schaal wrote:
> Hi Alexis,
> 
>   thanks a lot for the explanations. One item I am confused about is
>   that you write that TRIG_TIMER is not suitable for DIO, but in
>   cmd_write.c in your sample code, it is used for the analog write
>   without problems. Wouldn't one be able to just use the same clock
>   source for DIO as in analogue I/O? 
> 

The analog output subdevice has its own sampling source. That is why,
according to the command API logic, TRIG_TIMER is appropriate. It
indicates that the scans are triggered by a periodic timer delivered
by the analog output subsystem.

> Best wishes,
> 
> -Stefan
> 
> 
> 
> On Jul 12, 2010, at 15:29, Alexis Berlemont wrote:
> 
> > Hi,
> > 
> > Stefan Schaal wrote:
> >> Hi Alexis,
> >> 
> >>  I guess I slowly understand that my clocking signal connected to
> >>  scan_begin_arg has to come from an external DIO input, if
> >>  scan_bigin_src = TRIG_EXT, and that the insn instruction is still
> >>  needed to trigger the entire acquisition. 
> > 
> > Yes. The trigger instruction is needed so as to start the whole
> > acquisition (which is composed of many scans). A periodic external
> > signal is needed so as to trigger each scan.
> > 
> >> 
> >>  Alternatively, would it be possible to use the internal clocking signals like 
> >> 
> >> scan_bigin_src = TRIG_FOLLOW
> >> 
> >> or 
> >> 
> >> scan_bigin_src = TRIG_TIMER
> > 
> > I think you are right. If the sampling clock comes from another
> > subdevice, TRIG_EXT may not be the most appropriate constant. However,
> > the original comedi driver only expects TRIG_EXT even if... the
> > sampling signal is not external.
> > 
> > TRIG_TIMER does not seem suitable because it assumes an independant
> > sampling clock is available.  
> > 
> > And TRIG_FOLLOW may be the most appropriate one. We should modify the
> > driver so that TRIG_FOLLOW is used if the analog sampling clock is
> > chosen.
> > 
> >> 
> >> 
> >> if I try any of these sources, I get an error -22, and dmesg reports:
> >> 
> >> [195882.321300] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported
> >> 
> > 
> > For me, the command interface is an empty shell because the various
> > parameters (start_src, scan_begin_src, ...) and the values (TRIG_*)
> > are imposed. And, on the other side, the driver is fully in charge of
> > the command structure as it is. So, the comedi command imposes a
> > communication method but does not ease the driver's task of managing
> > it (errors checking, translation, etc.)
> > 
> > And, in our case: DIO, we may conclude that this imposed API does not
> > fit well: in scan_begin_arg, we have to pass an index which is
> > supposed to correspond to some sampling clock (which is specific to a
> > board). Then, we use a generic interface with board-specific
> > arguments.
> > 
> > So, to sum up, I understand your point: the way we control the driver
> > may not always be the most appropriate one. But, we inherited from
> > comedi both the interface and the drivers. 
> > 
> > On my side, I am working on trying to implement (as a background task)
> > a generic interface a little bit more based on discovery (query /
> > enum) that would render the command interface obsolete. Unfortunately,
> > I have nothing interesting to show yet.
> > 
> >> Best wishes,
> >> 
> >> -STefan
> >> 
> >> 
> > 
> 

-- 
Alexis.