Re: problem whit TRIG_INT

On Wed, 10 Nov 2004 corbetta_at_aero.polimi.it wrote:

> Hi,
> I am using this code to start a writing by a NI6713 but when I insert my 
> module (i'm working in kernel space) the command return always -1.
> int do_cmd(void)
> {
> int ret, i, n;	double s;
> comedi_cmd cmd;
> unsigned int chanlist[N_WRITE];
> comedi_insn insn;
> lsampl_t data_insn[1];	sampl_t preload;
> 
> 	memset(&cmd,0,sizeof(cmd));
>
> /* Set up channel list */
> for (i = 0; i < N_WRITE; i++) {
> 	chanlist[i] = CR_PACK(BUF_WRITE[i],4,AREF_GROUND);
> } 
>
> cmd.subdev = subdev;
> cmd.flags= TRIG_WAKE_EOS;
> 
> cmd.start_src = TRIG_INT;
> cmd.start_arg = 0; 
>
> cmd.scan_begin_src = TRIG_TIMER;
> cmd.scan_begin_arg = SAMP_TIME; 
>
> cmd.convert_src = TRIG_NOW;
> cmd.convert_arg = 0; 
>
> cmd.scan_end_src = TRIG_COUNT;
> cmd.scan_end_arg = N_WRITE; 
>
> cmd.stop_src = TRIG_NONE;
> cmd.stop_arg = 0;
> 
> cmd.chanlist = chanlist;
> cmd.chanlist_len = N_WRITE; 
>
> //	cmd.data=map;
> //	cmd.data_len=sizeof(sampl_t); 
> ret = comedi_command_test(dev,&cmd);
> printk("1st command test returned %d\n",ret); 
>
> ret = comedi_command_test(dev,&cmd);		printk("2nd command test 
> returned %d\n",ret);
> printk("CONVERT ARG: %d\n", cmd.convert_arg); 
>
> if (ret) {
> 	return ret;
> } 
>
> ret = comedi_command(dev,&cmd);
> printk("command returned %d\n",ret);
> 
> //	preload[0] = 1;
> /*	for (n = 0; n < BUFSIZE; n++) {
> s = (1. - range_min)/(range_max - range_min)*maxdata;
> preload = (sampl_t)(floor(s+0.5));
> comedi_data_write(dev, subdev, n , 0, AREF_GROUND, preload);}*/
> 
> //	n = N_WRITE * sizeof(sampl_t);		// 
> write(comedi_fileno(dev), (void *)preload, n);
> 
> 	memset(&insn, 0, sizeof(comedi_insn));
> 
> 	data_insn[0]=0; 
> insn.insn = INSN_INTTRIG;
> insn.n = 1;
> insn.subdev = subdev;
> insn.data = data_insn;
> insn.chanspec=CR_PACK(BUF_WRITE[0],4,AREF_GROUND);
> ret = comedi_do_insn(dev, &insn);
> 	if(ret<0){		comedi_perror("no cazzo internal trigger\n");
> } 
>
> 	return 0;
> }
> using > insmod signal_generator.o && dmesg
> -I recive this message
> -1st command test returned 0
> -2nd command test returned 0
> -CONVERT ARG: 0
> -command returned 0
> -ni_mio_common: DMA underrun
> -comedi2: ni_pcimio: timed out waiting for dma load
> -: unknown error 
>
> somebody can help me?

I am not too much of an expert in doing asynch AO in kernel space, but I 
believe you need to put some samples in one of comedi's data buffers so 
that you don't get a buffer underrun.

I don't know if this is definitely the case for asynch AO in kernel space, 
but I suspect you need to register a callback function with 
comedi_register_callback() using the COMEDI_CB_EOS mask. 
(comedi_register_callback() is a function not listed in the comedilib 
reference on the website but it is definitely present in the kernel API 
which is the one I am most familiar with).

For good measure, register the function before you call comedi_command() 
to issue the command.  Then I think you need to keep pumping samples into 
the comedi internal buffer for every scan.

Look at comedi_mmap() and some of the other functions that deal with 
comedi's data buffers.

Conspicuously missing are any functions to write samples into the data 
buffer -- which leads me to believe that I could be mistaken about how 
asynch AO works in comedi. However contradicting that is the fact that 
most of the driver code for asynch AO seems to be looking into this 
internal buffer.

I think your strategy of using comedi_data_write() in conjunction with 
aynch AO (commands) to load samples is not correct..  you need to work 
with comedi's internal buffer directly.  Comedi data write is not the 
way to do this.

Worst case scenario -- read the sourcecode to ni_mio_common.c and you 
will see that the function mite_handle_b_linkc() is responsible for 
producing that DMA underrun message.  It seems to have to do with the 
internal preallocated async buffer being empty (naturally it would be 
since you neglected to load any samples into it).

Sorry I couldn't give you any definite answers but hopefully the above 
comment will either get you investigating this problem more or will spark 
some flames/discussion in this mailing list to shed light on asynch AO in 
kernel space..

-Calin

Received on 2004-11-12Z16:33:51