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