Stefan Schaal wrote:
> Hi Alexis,
>
> I conceptually understand what you are telling us, but I am bit confused
> how to implement your advice:
>
> > So, Stefan, here is a quick solution:
> >
> > if you have access to your board you can choose one of these signals
> > (in which a regular pulse is occuring) and you can modify accordingly
> > the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c.
>
> The data structures in question are:
>
> /* The command to send by default */
> a4l_cmd_t cmd = {
> .idx_subd = -1,
> .flags = 0,
> .start_src = TRIG_INT,
> .start_arg = 0,
> .scan_begin_src = TRIG_EXT,
> .scan_begin_arg = 0, /* in ns */
> .convert_src = TRIG_NOW,
> .convert_arg = 0, /* in ns */
> .scan_end_src = TRIG_COUNT,
> .scan_end_arg = 4,
> .stop_src = TRIG_NONE,
> .stop_arg = 0,
> .nb_chan = 4,
> .chan_descs = chans,
> };
>
> a4l_insn_t insn = {
> .type = A4L_INSN_INTTRIG,
> .idx_subd = -1,
> .data_size = 0,
> };
>
>
> Thus, I assume you mean that
>
> scan_begin_src = TRIG_EXT
>
> should be modified to one of the enum items below? Are all these
> timers automatically running, or do they need to be configured, too?
> Sorry, I am a bit at a loss how to proceed.
Sorry for the delay.
I was not clear enough. In fact, scan_begin_arg should be
modified. scan_begin_src indicates the type of trigger and
scan_begin_arg gives an associated argument. In our case, it is the
signal number. Sorry for the comment (/* in ns */) which is an
inappropriate copy-paste (as a matter of fact, it is the whole command
interface which is unsuitable but that's another topic).
>
> Best wishes,
>
> -Stefan
>
>
> On Jul 5, 2010, at 15:02, Alexis Berlemont wrote:
>
> > Hi,
> >
> > Alexis Berlemont wrote:
> >> 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.
> >>
> >
> > Argh, I found it. I did not see an item in the url displayed above.
> >
> >
> > Here is an enum found in:
> > ftp://ftp.ni.com/support/daq/mhddk/examples/nimseries.zip
> >
> > // Field Accessors (Compile-time selectable)
> > typedef enum {
> > kCDO_Update_Source_SelectGround = 0,
> > kCDO_Update_Source_SelectPFI0 = 1,
> > kCDO_Update_Source_SelectPFI1 = 2,
> > kCDO_Update_Source_SelectPFI2 = 3,
> > kCDO_Update_Source_SelectPFI3 = 4,
> > kCDO_Update_Source_SelectPFI4 = 5,
> > kCDO_Update_Source_SelectPFI5 = 6,
> > kCDO_Update_Source_SelectPFI6 = 7,
> > kCDO_Update_Source_SelectPFI7 = 8,
> > kCDO_Update_Source_SelectPFI8 = 9,
> > kCDO_Update_Source_SelectPFI9 = 10,
> > kCDO_Update_Source_SelectRTSI0 = 11,
> > kCDO_Update_Source_SelectRTSI1 = 12,
> > kCDO_Update_Source_SelectRTSI2 = 13,
> > kCDO_Update_Source_SelectRTSI3 = 14,
> > kCDO_Update_Source_SelectRTSI4 = 15,
> > kCDO_Update_Source_SelectRTSI5 = 16,
> > kCDO_Update_Source_SelectRTSI6 = 17,
> > kCDO_Update_Source_SelectAI_Start = 18,
> > kCDO_Update_Source_SelectAI_Convert = 19,
> > kCDO_Update_Source_SelectPXI_Star_Trigger = 20,
> > kCDO_Update_Source_SelectPFI10 = 21,
> > kCDO_Update_Source_SelectPFI11 = 22,
> > kCDO_Update_Source_SelectPFI12 = 23,
> > kCDO_Update_Source_SelectPFI13 = 24,
> > kCDO_Update_Source_SelectPFI14 = 25,
> > kCDO_Update_Source_SelectPFI15 = 26,
> > kCDO_Update_Source_SelectRTSI7 = 27,
> > kCDO_Update_Source_SelectG0_Out = 28,
> > kCDO_Update_Source_SelectG1_Out = 29,
> > kCDO_Update_Source_SelectAnalog_Trigger = 30,
> > kCDO_Update_Source_SelectAO_Update = 31,
> > kCDO_Update_Source_SelectFreq_Out = 32,
> > kCDO_Update_Source_SelectDIO_Change_Detect_Irq = 33,
> > } tCDO_Update_Source_Select;
> >
> > So, Stefan, here is a quick solution:
> >
> > if you have access to your board you can choose one of these signals
> > (in which a regular pulse is occuring) and you can modify accordingly
> > the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c.
> >
> >>
> >>> 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.
> >
> > --
> > Alexis.
>
--
Alexis.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
