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