Re: [Xenomai-core] analogy - experimental branch

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

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.