Re: [Xenomai-core] analogy - experimental branch

[Alexis Berlemont <alexis.berlemont@domain.hid>]

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.