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