Re: [Xenomai-core] analogy - experimental branch
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 CPU0CPU1CPU2CPU3CPU4 CPU5CPU6CPU7 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.
Re: [Xenomai-core] analogy - experimental branch
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 CPU0CPU1CPU2CPU3CPU4
CPU5CPU6CPU7
56: 0 0 0 0 0
0 0 0 Analogy device
