Hi,

On Wed, Oct 28, 2009 at 7:08 AM, Remco den Breeje <[email protected]> wrote:
> Hi Peter,
>
> On Wed, Oct 28, 2009 at 3:08 AM, Peter Pastor <[email protected]> wrote:
> [...]
>> [   11.460737] analogy_ni_mio: Unknown symbol ni_tio_cmd
>> ...snip...
>
> I think Alexis solved that one with last nights commit
> 8063e1b21350bc6822565f29ad8d53c2a6491238

Yes indeed.

> If not, you may be able to work around that problem by removing the
> '_GPL' string in all EXPORT_SYMBOL_GPL statements in tio_common.c
>
> Cheers,
> Remco den Breeje
>
>>
>> r...@xenomai:~# lspci -v
>> ...snip...
>> 06:00.0 Class ff00: National Instruments Device 717f
>>     Flags: bus master, medium devsel, latency 64, IRQ 11
>>     Memory at f7dfe000 (32-bit, non-prefetchable) [size=4K]
>>     Memory at f7dff000 (32-bit, non-prefetchable) [size=4K]
>>     Kernel driver in use: mite
>>     Kernel modules: analogy_ni_pcimio
>> ...snip...
>>
>> r...@xenomai:~# lsmod | grep analogy
>> analogy_ni_tio         26852  0
>> analogy_8255            4388  0
>> analogy_ni_mite        12644  1 analogy_ni_tio
>> xeno_analogy           39108  3 analogy_ni_tio,analogy_8255,
>> analogy_ni_mite
>>
>> I don't really know how to use analogy_config... since
>>
>> r...@xenomai:/usr/xenomai/sbin# ./analogy_config analogy0 analogy_ni_mite
>> comedi_config: comedi_snd_attach failed ret=-22
>> when I run

The NI PCI MIO driver is composed of many kernel modules (ni_tio,
8255, mite, ni_mio), the features have ben distributed in various
modules so that they can be used by other drivers.
So you should insmod all of them (analogy_ni_mite, analogy_8255,
analogy_ni_tio, analogy_ni_mio, analogy_ni_pcimio).

The analogy driver "a4l_pcimio" will be registered with your last
insmod (analogy_ni_pcimio). You can check that by typing "cat
/proc/analogy/drivers", you will see only one entry: a4l_pcimio.

So the attach step with analogy_config must be performed only on it:
analogy_config analogy0 a4l_pcimio.

I already said that the names are confusing, I will fix that.

>> r...@xenomai:/usr/xenomai/bin# ./cmd_read
>> cmd_read: a4l_fill_desc failed (ret=-22)
>> *** glibc detected *** ./cmd_read: free(): invalid next size (fast): 
>> 0x08052008 ***
>> ======= Backtrace: =========
>> /lib/tls/i686/cmov/libc.so.6[0xb7f5f604]
>> /lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb7f615b6]
>> ./cmd_read[0x80496ae]
>> /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7f06775]
>> ./cmd_read[0x8048f41]
>> ======= Memory map: ========
>> 08048000-0804e000 r-xp 00000000 08:01 13109565   /usr/xenomai/bin/cmd_read
>> 0804e000-0804f000 r--p 00005000 08:01 13109565   /usr/xenomai/bin/cmd_read
>> 0804f000-08050000 rw-p 00006000 08:01 13109565   /usr/xenomai/bin/cmd_read
>> 08050000-08073000 rw-p 00000000 00:00 0          [heap]
>> b7d00000-b7d21000 rw-p 00000000 00:00 0
>> b7d21000-b7e00000 ---p 00000000 00:00 0
>> b7ecf000-b7edc000 r-xp 00000000 08:01 11894849   /lib/libgcc_s.so.1
>> b7edc000-b7edd000 r--p 0000c000 08:01 11894849   /lib/libgcc_s.so.1
>> ...
>>
>> which is I guess due to the unsuccessful analogy_config. My question is, 
>> which driver do I have to use ?

Yes, you are right.
It is a bug on my todo list: cmd_read / cmd_write do not behave
properly when we use unattached device as argument; the error handling
path must be fixed.

>>
>> Thanks,
>>  peter
>>
>> On Thu, Oct 22, 2009 at 11:49 PM, Alexis Berlemont <[email protected]> 
>> wrote:
>>>
>>> Hi,
>>>
>>> On Thu, Oct 22, 2009 at 7:30 AM, Peter Pastor <[email protected]> 
>>> wrote:
>>> > Hi Alexis,
>>> >
>>> > Sorry for the delay, I was out of town.
>>> >
>>> > I have tried the statical configuration and it seemed to work, i.e. I 
>>> > could
>>> > execute the example program /usr/xenomai/bin/cmd_read. However, I wanted 
>>> > to
>>> > run the task in real-time and added the -r option which results in
>>> > r...@xenomai:/usr/xenomai/bin# ./cmd_read -vr
>>> > cmd_read: switching to real-time mode
>>> > cmd_read: device comedi0 opened (fd=0)
>>> > cmd_read: basic descriptor retrieved
>>> >      subdevices count = 14
>>> >      read subdevice index = 0
>>> >      write subdevice index = 1
>>> > cmd_read: complex descriptor retrieved
>>> > cmd_read: channel 0
>>> >      ranges count = 7
>>> >      range's size = 16 (bits)
>>> > cmd_read: channel 1
>>> >      ranges count = 7
>>> >      range's size = 16 (bits)
>>> > cmd_read: channel 2
>>> >      ranges count = 7
>>> >      range's size = 16 (bits)
>>> > cmd_read: channel 3
>>> >      ranges count = 7
>>> >      range's size = 16 (bits)
>>> > cmd_read: scan size = 8
>>> > cmd_read: size to read = 800
>>> > cmd_read: command successfully sent
>>> > 0xff 0xff 0xff 0xff 0xff 0xff 0x81 0xf9
>>> > 0xff 0xff 0xff 0xff 0xff 0xff 0xca 0xfb
>>> > ...snip...
>>> > 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
>>> > cmd_read: comedi_read failed (ret=-2)
>>>
>>> -2 is -ENOENT, which means there is nothing more to acquire. The
>>> return code should have been 0 but I 'd rather send -2, which is not
>>> very compliant. It is something I need to work on.
>>>
>>> > The cmd_write however, seems to work
>>> >
>>> > r...@xenomai:/usr/xenomai/bin# ./cmd_write -rv
>>> > cmd_write: switching to real-time mode
>>> > cmd_write: device comedi0 opened (fd=0)
>>> > cmd_write: basic descriptor retrieved
>>> >      subdevices count = 14
>>> >      read subdevice index = 0
>>> >      write subdevice index = 1
>>> > cmd_write: complex descriptor retrieved
>>> > cmd_write: channel 0
>>> >      ranges count = 3
>>> >      range's size = 16 (bits)
>>> > cmd_write: channel 1
>>> >      ranges count = 3
>>> >      range's size = 16 (bits)
>>> > cmd_write: scan size = 4
>>> > cmd_write: size to write  = 400
>>> > cmd_write: command successfully sent
>>> > cmd_write: 400 bytes successfully written
>>> >
>>> > also...
>>> > r...@xenomai:/usr/xenomai/bin# ./insn_read -rv
>>> > insn_read: switching to real-time mode
>>> > insn_read: device (null) opened (fd=0)
>>> > insn_read: basic descriptor retrieved
>>> >      subdevices count = 14
>>> >      read subdevice index = 0
>>> >      write subdevice index = 1
>>> > insn_read: complex descriptor retrieved
>>> > insn_read: channel width is 16 bits
>>> > insn_read: global scan size is 20
>>> > 0xff 0xff
>>> > 0x0 0x0
>>> > 0xff 0xff
>>> > 0x0 0x0
>>> > 0xff 0xff
>>> > 0x0 0x0
>>> > 0xff 0xff
>>> > 0x0 0x0
>>> > 0xff 0xff
>>> > 0x0 0x0
>>> > insn_read: 20 bytes successfully received
>>> >
>>> > What I would like to make sure is that I can write to comedi0 without 
>>> > having
>>> > mode switches. Therefore I copied cmd_write and added a rt_task_spawn to
>>> > make sure that the task_body runs in real-time (even though the -r option
>>> > results in the same behavior.) This way, I could add/change code to check
>>> > for mode switches... However, since unfortunately I am debugging things
>>> > remotely I cannot "see" the output (the display) of our oscilloscope that 
>>> > is
>>> > connected to the pci express card. I'll send an email as soon as I know
>>> > more.
>>>
>>> Be careful with the printf() I inserted in the test programs cmd_read,
>>> cmd_write; they will make you switch in the secondary domain.
>>>
>>> > Besides that, I updated to your latest xenomai and re-compiled having the
>>> > comedi drivers compiled as loadable modules. After booting the new kernel 
>>> > I
>>> > can see the following:
>>> >
>>> > xenomai:~> uname -a
>>> > Linux xenomai 2.6.30.5-xenomai-ipipe-comedi #6 SMP Wed Oct 21 20:05:37 PDT
>>> > 2009 i686 GNU/Linux
>>> > xenomai:~> lspci -v
>>> > ...snip...
>>> > 06:00.0 Class ff00: National Instruments Device 717f
>>> >     Flags: bus master, medium devsel, latency 64, IRQ 11
>>> >     Memory at f7dfe000 (32-bit, non-prefetchable) [size=4K]
>>> >     Memory at f7dff000 (32-bit, non-prefetchable) [size=4K]
>>> >     Kernel driver in use: mite
>>> >     Kernel modules: comedi_ni_pcimio
>>> > ...snip...
>>> > xenomai:~> lsmod | grep come
>>> > comedi_ni_tio          26884  0
>>> > comedi_8255             4420  0
>>> > comedi_ni_mite         12708  1 comedi_ni_tio
>>> > xeno_comedi            39908  3 comedi_ni_tio,comedi_8255,comedi_ni_mite
>>> >
>>> >
>>> > However, the problem is that there is:
>>> >
>>> > r...@xenomai:/usr/xenomai/sbin# ./comedi_config comedi0 comedi_pcimio
>>> > comedi_config: comedi_snd_attach failed ret=-22
>>> >
>>> > also...
>>> >
>>> > r...@xenomai:/usr/xenomai/sbin# ./comedi_config comedi0 comedi_ni_mite
>>> > comedi_config: comedi_snd_attach failed ret=-22
>>> >
>>> > r...@xenomai:/usr/xenomai/sbin# dmesg
>>> > ...snip...
>>> > [   11.298460] Comedi: MITE: Available NI device IDs: 0x717f(used)
>>> > [   11.305333] comedi_8255: module license 'unspecified' taints kernel.
>>> > [   11.305337] Disabling lock debugging due to kernel taint
>>> > [   11.331840] comedi_ni_mio: Unknown symbol ni_tio_handle_interrupt
>>> > [   11.331936] comedi_ni_mio: Unknown symbol ni_tio_set_mite_channel
>>> > [   11.331986] comedi_ni_mio: Unknown symbol ni_tio_cmd_mask
>>> > [   11.332171] comedi_ni_mio: Unknown symbol ni_tio_init_counter
>>> > [   11.332317] comedi_ni_mio: Unknown symbol ni_tio_winsn
>>> > [   11.332416] comedi_ni_mio: Unknown symbol ni_gpct_device_destroy
>>> > [   11.332466] comedi_ni_mio: Unknown symbol ni_tio_insn_config
>>> > [   11.332696] comedi_ni_mio: Unknown symbol 
>>> > ni_tio_acknowledge_and_confirm
>>> > [   11.332786] comedi_ni_mio: Unknown symbol ni_tio_cmdtest
>>> > [   11.332921] comedi_ni_mio: Unknown symbol ni_tio_cancel
>>> > [   11.332976] comedi_ni_mio: Unknown symbol ni_gpct_device_construct
>>> > [   11.333139] comedi_ni_mio: Unknown symbol ni_tio_rinsn
>>> > [   11.333189] comedi_ni_mio: Unknown symbol ni_tio_cmd
>>> > ...snip...
>>> >
>>> > How can I fix this ? Or should I simply work with the statical linked 
>>> > comedi
>>> > drivers ??
>>>
>>> I will update my git repository soon with these fixes. However, could
>>> you switch to the analogy branch ? As you may know, comedi/RTDM has
>>> been renamed as analogy:
>>> https://mail.gna.org/public/xenomai-core/2009-09/msg00016.html
>>>

Alexis.

_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help

Reply via email to