From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4644C144.1020004@domain.hid> Date: Fri, 11 May 2007 21:17:24 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <001701c793ee$85d24d00$c67ba8c0@domain.hid> In-Reply-To: <001701c793ee$85d24d00$c67ba8c0@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig33C0E001B8D3C5DF0AFD27A5" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] Serial Port Driver(rtser): No RTSER_RTIOC_WAIT_EVENT List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jonas Witt Cc: xenomai@xenomai.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig33C0E001B8D3C5DF0AFD27A5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jonas Witt wrote: > Jonas Witt wrote: >> Jonas Witt wrote: >>> Jonas Witt wrote: >>>>> Hi everybody, >>>>> >>>>> =20 >>>>> >>>>> i am having a problem with the serial port driver in xenomai for a > while >>>>> now.. >>>>> >>>>> =20 >>>>> >>>>> I have tried different programs like >>>>> http://www.captain.at/xenomai-serial-port-example.php >>>>> >>>>> =20 >>>>> >>>>> I have also changed the code of cross-link.c to use the same port f= or >>>>> writing and reading (as i only have one serial port in my computer)= =2E >>> Opening >>>>> a port and writing the configuration seems to work form e.. also >>> writing. >>>>> The Problem stems from the call to: >>>>> >>>>> =20 >>>>> >>>>> rt_dev_ioctl(read_fd, RTSER_RTIOC_WAIT_EVENT, &rx_event); >>>>> >>>>> =20 >>>>> >>>>> which keeps waiting forever and never receives an interrupt. I trie= d 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 call= s to >>>>> rt_dev_write do not work from non-xenomai-tasks (which should reall= y 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 ma= y be >>>> wrong, if there is nothing on rx, your port configuration might b= e >>>> broken. >>>> >>>> o try the driver from trunk, it can handle PnP-related issues (hard= ware >>>> 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=3D/dev/sda1 ro >> 8250.nr_uarts=3D0 >>>> xeno_16550A.ioaddr=3D0x3f8 xeno_16550A.irq=3D4 >>>> >>> 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 coul= d >>> 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= =2E 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 uncom= mon. >>> >>> (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 i= rq >>> 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 'ma= ke' >>> 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 Linu= x >>> port with setserial, and load the RT driver as a module. Then, if thi= s >>> 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 disp= lays >>> 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 th= e > time >>> (although information is successfully written to the port, judging fr= om > 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 devic= e >> if 8250 is not loaded and takes over the PnP work. >> >> Jan >=20 > I already tried my luck with a modular driver.. does not work either.. >=20 :-/ > Now i compiled a new 2.6.20-kernel with xenomai-trunk. I tried to modpr= obe > as usual: > modprobe xeno_16550A ioaddr=3D0x3f8 irq=3D4 > but somehow the 'ioaddr'-parameter is not accepted by the module.. did > something change there? Yep, it has been refactored to "io=3D" (like other Xenomai drivers). Jan --------------enig33C0E001B8D3C5DF0AFD27A5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGRMFEniDOoMHTA+kRAkEmAJ9Nu05CfxndZJqg32HILk0d4mBJzACfZhNj RDO9gs9pv/vFwRM0zAHk+3o= =waHm -----END PGP SIGNATURE----- --------------enig33C0E001B8D3C5DF0AFD27A5--