Re: [Xenomai-help] Serial Port Driver (rtser): NoRTSER_RTIOC_WAIT_EVENT

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 4286 bytes --]

Jonas Witt wrote:
> Jonas Witt wrote:
>> Jonas Witt wrote:
>>>> Hi everybody,
>>>>
>>>>  
>>>>
>>>> i am having a problem with the serial port driver in xenomai for a while
>>>> now..
>>>>
>>>>  
>>>>
>>>> I have tried different programs like
>>>> http://www.captain.at/xenomai-serial-port-example.php
>>>>
>>>>  
>>>>
>>>> I have also changed the code of cross-link.c to use the same port for
>>>> writing and reading (as i only have one serial port in my computer).
>> Opening
>>>> a port and writing the configuration seems to work form e.. also
>> writing.
>>>> The Problem stems from the call to:
>>>>
>>>>  
>>>>
>>>> rt_dev_ioctl(read_fd, RTSER_RTIOC_WAIT_EVENT, &rx_event);
>>>>
>>>>  
>>>>
>>>> which keeps waiting forever and never receives an interrupt. I tried a
>>>> self-made loopback-adapter and a sensor with a serial interface (so at >
>> least
>>>> _something_ should come back). Nothing worked. The serial port is
>> working
>>>> fine with the linux-driver, though. I already figured that the calls to
>>>> rt_dev_write do not work from non-xenomai-tasks (which should really be
>>>> emphasized in the documentation..)
>>>>
>>> Some suggestions:
>>>
>>>  o check the hardware configuration (ie. the module parameters of
>>>    xeno_16550A) twice, you can easily get them wrong
>>>
>>>  o check /proc/xenomai/irq for any progress on transmission as well as
>>>    on reception. If there is nothing happen on tx, the IRQ number may be
>>>    wrong, if there is nothing on rx, your port configuration might be
>>>    broken.
>>>
>>>  o try the driver from trunk, it can handle PnP-related issues (hardware
>>>    gets powered off when Linux driver is removed)
>>>
>>> Jan
>>>
>>> Thanks for the fast reply!
>>>
>>> I am using the following kernel parameters:
>>>
>>> kernel		/boot/vmlinuz-2.6.19-ipipe root=/dev/sda1 ro
> 8250.nr_uarts=0
>>> xeno_16550A.ioaddr=0x3f8 xeno_16550A.irq=4
>>>
>> OK, that leads to another suggestion: try going the modular path for
>> xeno_16550A first, it's the more common one. Above /should/ be no
>> problem /wrt the the RT driver, but kicking 8250 out of the game could
>> cause that PnP power issue I sketched.
>>
>>> I got these settings from setserial prior to disabling the kernel-driver.
> To
>>> be honest i don't know how to 'check' /proc/xenomai/irq for progress. I
> took
>>> a look at the folder prior to and while running my modified
> cross-link-code
>>> but irq is an empty file in both cases. Is there some special
> trick/function
>>> to handle the files in the proc-folder?
>> You mean the file is existing but empty??? That would be fairly uncommon.
>>
>> (without any driver loaded)
>> # cat /proc/xenomai/irq
>> IRQ         CPU0
>> 217:           0
>> 226:           0         [virtual]
>>
>> The serial driver pops up here once the port is opened. The per-cpu irq
>> hit counter should then increase as interrupts come in.
>>
>>> To the last point.. so there is an updated version of the driver
>> available?
>>> I think i will try that one.. is it just a question of executing 'make'
>> and
>>> modprobing or are there more actions involved?
>> No, it's not that easy (more files, changed Makefiles and RTDM API).
>> First try the modular driver path, ie. keep 8250, switch off the Linux
>> port with setserial, and load the RT driver as a module. Then, if this
>> doesn't help, you could consider upgrading your Xenomai installation (at
>> least for a test) to SVN trunk.
>>
>> Jan
> 
> Ah, ok.. ehem... i tried to look at the file with gedit.. and it displays
> nothing.. ;)
> Now i get:
> 
> IRQ         CPU0
>   4:           0         rtser0
> 216:         521         [timer]
> 226:         620         [virtual]
> 
> This is how it looks like after the program starts.. after that it increases
> just the [virtual] and the [timer] counter . Rtser0 stays at 0 all the time
> (although information is successfully written to the port, judging from the
> return value of rt_dev_write).
> 
> So i guess that is where the problem lies.. what can I do about that?

Apply the other suggestion I made. You may try to talk to a dead device
if 8250 is not loaded and takes over the PnP work.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]